Time for us to see where load sharing can serve as a benefit as it usually does with RIP.

We saw some load balancing going on and we chatted about it a little bit during our auto summarization lab and load balancing wasn’t working in our favor, but that was because auto summarization was left on. In this lab as with most production networks, it is off.
What I’ve done here is taking our original serial network (our original frame network) between routers 1, 2 and 3 (172.12.123.0 / 24) and I’ve added a 172.12.23.0 / 24 subnet that is being used on routers 2 3 and 4 on their fast ethernet interfaces and also router 4 is running a loop back, (4.4.4.4 /24 )
The entire network is configured for RIP. You’ve seen these commands over and over so I’ve gone ahead and done that for you this time. And it’s the usual…the network commands version 2. No auto, and you’re ready to go.
R1 actually has two loop free paths to send packets when it sends packets to loopback 4.
The packets could go to R2’s serial interface, then R2 would route them out its fast ethernet interface. R4 would receive them on its fast ethernet interface and then of course the loopback being connected there’s no problem there.
The packets from one to four can also leave R1 and go to R3. R3 receives them on a serial, sends them out fast ethernet interface, R4 receives them on its fast ethernet interface and then the packets are out the loopback.
So it would be kind of a shame to use one of those paths exclusively and just leave the other one alone. Because it is more efficient if we do some kind of a load balancing (hence the name equal costs load balancing) because it’s much more efficient to use both paths and send roughly half the data over each one .
So that’s what we’re doing here and actually the great thing about RIP is we don’t have to lift a finger to make that happen with equal costs load balancing.
Let’s go ahead and I’ll send some pings over to R4.

But you know Ping is a great place to start a connectivity test and to start a lab, and to start your troubleshooting. But it’s a little bit limited because ping tells you if you have connectivity, ping tells you if you don’t have connectivity, It can even tell you that you have some connectivity but not as much as you want.
The thing is though we have no idea what path these packets took to get to 4.
If we’d like to test our load sharing, maybe we could use a close cousin of the ping command ( the trace route command ) to make that happen.
Before we get to that, let’s take a look at our routing table.

You can also use ‘show IP route’ for network number and put them like that, and it’s going to show you how many subnets it knows about redistributing via RIP (they’re known via RIP) and you can see exactly what we would see in the RIP routing table or in the IP routing table as a whole.
And we have the usual RIP entry. There’s 4.4.4.0 that’s the one known subnet.
We know the administrative distance. we know what those numbers are.
But why do I have two routes here?
With RIP, you’re much more likely to have an exact match in your route metrics at the beginning of a lab or a production network as you will with the EIGRP or SPF just because EIGRP and OSPF metrics are much more complex. So the numbers frankly are going to be a lot larger. You’re not going to be dealing with one number. You can be dealing in anywhere from two numbers to literally eight or nine numbers maybe more.
But here with RIP, RIP says “hey these paths are absolutely equal. I have two paths. I’m getting via my updates and I put them both on the table because they have equal cost.” And now we’re going to send roughly half of the data going to 4.4.4.0 to go through 123.2 over R2. The other half roughly 123.3. I say roughly because it’s rare that it’s going to be exact but it’s going to be pretty close.
Now what if we wanted to change that a little bit? And how do we know how many paths RIP will load balance over by default?
It’s four by default. And if you run ‘show IP protocols’ :

That’s what this maximum path is referring to.
That really doesn’t give you a good description. Maximum path for what?
That that is the maximum number of paths we’re using right now for Equal Cost Load Sharing and that’s by default.
Now if you want to change that, you shoud run ‘Maximum-path’.

So if you’ve got a lot of rip paths you want to load balance over, you could certainly raise that . You may have reason to lower the number. Usually people just leave it right at 4.
Notice that you don’t have a zero here, and you usually see a zero any time you see numbers listed in ios help ! Usually when we put a zero, we’re disabling something or we’re turning a timer off. We don’t have that here.
But if for whatever reason you wanted to disable Equal Cost Load Sharing, just set the maximum path to one. You can’t set it to zero.
Two important notes regarding ‘maximum path’ command:
Cisco hardware and IOS versions (different iOS versions) offer a range of maximum values for the ‘maximum path’ command. You’ll never be able to set it to 0 but the maximum is not always going to be 32.
That’s more of a real world thing.
If you want to disable equal Cost Load Sharing for any reason, set that value to one.
Trace Route Command
Primarily you use this as a troubleshooting command. You can also test your load balancing with it.
And first I’ll run one here on a PC and I’m going to run a ‘trace rt’
Watch this on your exam!
‘trace rt’ is on a Windows machine and ‘trace route’ (the full word) is is on a Cisco device.
So let’s do a ‘tracert’ here and I’m just going to do it to YouTube.com

Notice that next to the number you’ve got three timers there. What a trace route does, it sends three probes out at the very beginning, and usually what you get in return is one IP (50.207.95.145) and you can see Richmond Virginia which is where I am, and then you can see Ashburn. So we’re starting to get a little bit closer.
But along with these names you also see the IP addresses and where trace arti and trace route both come in handy, is when you are trying to locate where the problem is because that’s where that limitation with ping comes in.
Between me and YouTube there could be you 15 or 20 routers. And if I’m actually trying to do some troubleshooting and find out why staplesmillrd.va.richmond.comcast.net can’t get to YouTube, I could use ‘trace route’ to see how far we’re actually getting.

So if I start seeing a lot of timeouts at this point it’s like OK 209.85.251.243 was the IP address of the last device that we could actually get to.
So we’ll see trace complete there.

And that’s it.
It’s going to look a lot like what we’re about to see on our Cisco device. Just not as many IP addresses.
There is a great way to test your load balancing . You’ll notice when we sent the ‘tracert’ out, we got one IP address on each line.
You can see the exact path and then once we got past the numbers, you can see the 7th device, the 8th device etc.

And right before we got to the end here we got a request timed out which is not uncommon. When you keep getting these asterisks, you need to say: “OK that’s as far as we’re going to get.”
So let’s go ahead and do a ‘trace route’ on 4.4.4.4 from R1 and see exactly how the packets are getting there. (or those probes that we sent out)

That should pretty much be it.
So there is the route and we expected to be pretty short.
Notice: with line 1 we have three addresses.(Or rather we have two addresses but one of them are listed Twice) and then the second one is just 23.4 which is that Ethernet interface down on R4.
So what’s going on with those first three numbers?
That’s how Load Balancing is working because that means the first trace route probe was sent to 123.2, the second one to 123.3, and then the third went to 123.2 again and then when they returned that value, that’s why you see three IP addresses there.
You’re only going to see that, if you have some kind of load balancing going on. Otherwise you would just see one address per line.
Anytime you see this it’s a real tip off that your load balancing is working.
Now if you wanted to send more probes.
Let’s say that you wanted to send a certain number of probes then you could use what we call “extended trace route” and you just enter the ‘traceroute’ command and then hit enter and then it’s going to ask you for the protocol IP.
Anytime Cisco prompts you for information and there’s an entry in a bracket like this, if you hit enter you’re accepting that default.
The target IP address is 4.4.4.4.
Source address: We’re going to keep that at the default we’re not going to change that numeric display: No
Timeout: keeping three seconds apart.
I’m going to send 10 probes out.

I’m going to take the defaults for everything else and there we go. Then all of a sudden we’ve got you know 10 entries there and I’m going to go ahead and stop the trace route out there because at 23.4 we know the path.

So what you would see there is 32 msec show five times, and then five probe time outs when you get at the end, because we sent 10 probes. But you can see the first one you know it’s 2 3 2 3 2 3 2 3 2 3 and that means indeed that your load sharing is working correctly.
Now about that ‘Type escape sequence to abort’. What is it?
It’s the same one as with ping. Its control + shift + six + control + shift + six .
Let me just trace routes something that doesn’t exist here.

So you trace route something and you put an IP address in there that can’t be traced.
Or you just enter the wrong one and you realized after one address…
As soon as I enter escape sequence, it returns you to the prompt.
Version Mismatches and Debugging Tips

I’ve gotten rid of a couple of networks from the previous lab and added a couple of loop backs back.
So the only thing we’re dealing with here is the 172.12.123 user and network between routers one, two and three and a loopback on 2, a loop back on 3. R4 is out of the picture entirely.
I cleaned all the RIP commands off with no router RIP before I started this. Let’s just go ahead and quickly configure those three routers. Never hurts to reinforce these commands



I’d have to go back and put the loop back on too.


We’re all set.
We got all the network commands, got no auto, got Version 2 on all my routers, and I’m just going to check this before I proceed with my lab…

and I don’t have anything yet .It’s kind of unusual.
I could do a ‘clear IP route *’ and would do it again:

and I still don’t… I’m sure you saw exactly what I did wrong there. This is an easy mistake to make, but it also leads into something that’s very important as far as debugs go.
To try to figure out why I still don’t have my routes I could go out and look at the config and try to spot it, and the one thing I want to warn you against there is that your eyes can play tricks on you especially with commands that you see in a config often, and especially on your exam I would watch “auto summary” and “no auto summary” in the Config because we’re all so used to seeing “no auto summary” in a rip config that when we just have “auto summary” your mind’s eye tends to put a ‘no’ in front of it.


So just read that carefully.
That also goes for the version number, because what I did here, is just have a little slip of the pinky finger there when I was typing ‘2’ and I slid over and I hit the ‘1’ instead.
So that’s exactly why I don’t have any routes right now.
I could also look in ‘show ip protocols’

and right here in the middle (default version control) we’re sending version 1, receiving version 1, I put version 2 on the other two routers. So obviously we’re going to have a bit of a problem there.
Note: Get used to running debugs.
Be sure to run them when things are running correctly. Cause it’s a wonderful reinforcement of what’s going on and where updates are going and what updates are kept in a packet . It really reinforces the theory marvelously and it’s the biggest thing that I wish someone had told me when I was studying for the CCNA!
Never practice debugs in a production environment but always run debugs as you learn them if you get the chance, and see what’s going on when things are running correctly. because then you have a little reference when things aren’t running correctly.
it’s going to be yelling at us what the problem is.
I want you to see what this looks like as far as the debug goes.

You can see that I’m running version 1 sending request, and I’m broadcasting it because it’s going out to 255.255.255.255

and hey we’re ignoring some version 2 packets.
Not a good idea but that’s actually what’s going to happen when the interface is configured to accept only version 1 (as it is here) and we got Version 2 packets coming out.
Let’s fix it.

So now let’s see if that has had the desired effect yet.

You’re not getting a ton of information… You’re seeing the updates, you’ve seen where they came from and where the hops are.
People are a little intimidated by debugs
Yes this one was easy to spot in the conflict.
But you’re going to run into problems that aren’t as easy as just as looking at the Config.
So learn this debug and then learn all the other debugs that you’re introduced to in your studies as you go along. Don’t let them intimidate you.
Like everything else in Cisco it’s a little odd at first it becomes second nature after a while.