Routing Issues

[precious]

I recently dealt with a client’s network outage caused by a misconfigured router. I had to dig into the routing tables and found that one static route was pointing to the wrong gateway. Once corrected, the network was restored. Have you encountered similar routing issues in your teaching, and how do you explain routing table troubleshooting to your students?

 

[Jeff Strain]

I recently dealt with a client’s network outage caused by a misconfigured router. I had to dig into the routing tables and found that one static route was pointing to the wrong gateway. Once corrected, the network was restored. Have you encountered similar routing issues in your teaching, and how do you explain routing table troubleshooting to your students?

Oh the stories... So many minor mistakes can bring the network to its knees. I have seen this multiple times as it depends on the weight of the route where it falls in the pecking order.

It is hard to teach students that such minor changes can reign chaos. I try to do this by providing them a place where they can constantly cause themselves problems so that they learn. We should celebrate the depth of learning that comes from such crippling minor changes and point out that we like these in the classroom so the painful learning occurs there and not on the job.

So, I do not find myself teaching routing often, but maybe intentionally having students do this, break their environment, and then discuss it would not be a bad exercise.

 

[precious]

Oh the stories... So many minor mistakes can bring the network to its knees. I have seen this multiple times as it depends on the weight of the route where it falls in the pecking order.

It is hard to teach students that such minor changes can reign chaos. I try to do this by providing them a place where they can constantly cause themselves problems so that they learn. We should celebrate the depth of learning that comes from such crippling minor changes and point out that we like these in the classroom so the painful learning occurs there and not on the job.

So, I do not find myself teaching routing often, but maybe intentionally having students do this, break their environment, and then discuss it would not be a bad exercise.

Exactly Jeff Strain! Hands-on experience with real-world issues is invaluable. Breaking things in a controlled environment is the best way to learn before facing these challenges in the field.

 

[Trevor Chandler]

I recently dealt with a client’s network outage caused by a misconfigured router. I had to dig into the routing tables and found that one static route was pointing to the wrong gateway. Once corrected, the network was restored. Have you encountered similar routing issues in your teaching, and how do you explain routing table troubleshooting to your students?

My explanation begins by having students to look at the logs on the router!

 

[Rick Butler]

I recently dealt with a client’s network outage caused by a misconfigured router. I had to dig into the routing tables and found that one static route was pointing to the wrong gateway. Once corrected, the network was restored. Have you encountered similar routing issues in your teaching, and how do you explain routing table troubleshooting to your students?

When I've taught routing, I always started on the whiteboard, building a pseudo table to teach the very basics and move on from there.

I've always taught that if you can avoid a static entry on a routing table, if there's any way, do so - routing protocols are smarter. And if you have to have a static entry, document the heck out of it, so someone that comes behind knows. The way I see it, these days, if you have to use a static entry, you're trying to do something unconventional or weird.

That's where the documentation comes in - because "well, it was a good idea when I put it in there" will turn into "what the heck was this fool thinking?". In the OP's example, I think that entry was correct at one time, that it was working once and then one day, it wasn't working. Perhaps the gateway was changed, but no one bothered to look at the static routes in the other routers.

However, these bugs are also great to teach. Using something like GNS3 to build a network up and test with, has been a mainstay for me over the years.

/r

 

[Brian Ford]

My explanation begins by having students to look at the logs on the router!

To expand on Trevor's answer about looking at the logs; investigate the routing issue by determining the scope of the problem. Expand on this by using ping and traceroute. Can users connect to some networks (sites) but not others? Statics are often used in two scenarios. #1 when the network is really simple and the architect wants to dictate the traffic path (think about a simple home /office router or a network with one ISP connection). Another use case is when the network is more complex and multiple paths (multiple ISPs) exist between two networks. In this case you might want to override or backup the route discovered via a routing protocol. And this is where route weighting comes in to the discussion.

 

[Carnegie]

To expand on Trevor's answer about looking at the logs; investigate the routing issue by determining the scope of the problem. Expand on this by using ping and traceroute. Can users connect to some networks (sites) but not others? Statics are often used in two scenarios. #1 when the network is really simple and the architect wants to dictate the traffic path (think about a simple home /office router or a network with one ISP connection). Another use case is when the network is more complex and multiple paths (multiple ISPs) exist between two networks. In this case you might want to override or backup the route discovered via a routing protocol. And this is where route weighting comes in to the discussion.

@Brian Ford, great tips. A favorite troubleshooting Windows command line tool is PathPing that combines ping and traceroute into one tool.

Usage: pathping [-g host-list] [-h maximum_hops] [-i address] [-n]
                [-p period] [-q num_queries] [-w timeout]
                [-4] [-6] target_name

Options:
    -g host-list     Loose source route along host-list.
    -h maximum_hops  Maximum number of hops to search for target.
    -i address       Use the specified source address.
    -n               Do not resolve addresses to hostnames.
    -p period        Wait period milliseconds between pings.
    -q num_queries   Number of queries per hop.
    -w timeout       Wait timeout milliseconds for each reply.
    -4               Force using IPv4.
    -6               Force using IPv6.

 

[precious]

When I've taught routing, I always started on the whiteboard, building a pseudo table to teach the very basics and move on from there.

I've always taught that if you can avoid a static entry on a routing table, if there's any way, do so - routing protocols are smarter. And if you have to have a static entry, document the heck out of it, so someone that comes behind knows. The way I see it, these days, if you have to use a static entry, you're trying to do something unconventional or weird.

That's where the documentation comes in - because "well, it was a good idea when I put it in there" will turn into "what the heck was this fool thinking?". In the OP's example, I think that entry was correct at one time, that it was working once and then one day, it wasn't working. Perhaps the gateway was changed, but no one bothered to look at the static routes in the other routers.

However, these bugs are also great to teach. Using something like GNS3 to build a network up and test with, has been a mainstay for me over the years.

/r

Thanks, Rick! I agree—dynamic protocols are usually better, and documentation is key for static routes. In this case, the gateway changed, but the static route wasn’t updated. I'll use GNS3 more in simulations to show how to spot these issues. Great approach!

 

[precious]

@Brian Ford, great tips. A favorite troubleshooting Windows command line tool is PathPing that combines ping and traceroute into one tool.

Usage: pathping [-g host-list] [-h maximum_hops] [-i address] [-n]
                [-p period] [-q num_queries] [-w timeout]
                [-4] [-6] target_name

Options:
    -g host-list     Loose source route along host-list.
    -h maximum_hops  Maximum number of hops to search for target.
    -i address       Use the specified source address.
    -n               Do not resolve addresses to hostnames.
    -p period        Wait period milliseconds between pings.
    -q num_queries   Number of queries per hop.
    -w timeout       Wait timeout milliseconds for each reply.
    -4               Force using IPv4.
    -6               Force using IPv6.

Thanks, Brian! I used ping and traceroute to narrow it down. The static route was key since the client had one ISP. Great point about route weighting—I'll keep that in mind for complex networks!