Static and Policy Based and GRE...Oh My

So I have been working through the workbook from INE.  I skipped the Layer 2 section because while I have the switches, they are not hooked up.  I created a base topology in GNS3 using 20 routers connected to a single dumb layer 2 switch and it works for testing everything else.  I am okay with doing this right now since I am only learning the technology but for full labs, I will have to go back to using physical switches and a break out switch and Q-in-Q trunking. 

I need to correct something I said in an earlier post as well.  I have now noticed that there is one Foundation Lab at the bottom of the workbook.  That is a full blown lab so that will be good but first I want to get through all of the Technology Labs first.

So, anyways, on to the fun stuff. I did the IP Routing section of the workbook.  Most of it was pretty much common knowledge.  Things like longest match routing, PBR, floating static routes, and GRE tunneling.  All in all, it wasn't bad.  But there were a couple of things that I didn't know and found interesting. 

First, I learned about a new command that can be useful.  It is show ip static route.  It shows what static routes are installed in the route table and how they got there.  I can see this being useful not only for floating static routes but also think about when doing summary addresses and it creates a NULL route.  Be useful to fully check that.

I also had to change how I do tracking.  I remember tracking SLA stats being track # rtr #.  I had to do it this time as track # ip sla # <state|reachability>.  Just a syntax change that is good to know.

Basic GRE routing wasn't really a problem before.  I just had to remember to add the command tunnel mode gre ip so that the mode was correctly set.  Again, a quick little learn.

Now what if there are two GRE tunnels and one is a backup.  What do you do?  Well, I didn't know that  you can add the backup interface command to a tunnel so that when the primary tunnel goes down a backup one will come up.  The primary tunnel though has to be a point-to-point tunnel.  This cannot work on a multipoint GRE tunnel.  Also there is a problem with this.  If one tunnel interface goes down on one router, the other router doesn't know and will still try to route down it.

How do you fix the two tunnels not acting together?  Use keepalives.  These can be set up on one side of the tunnel but for better tracking do it on both.  Great way to test your main tunnel and bring up the backup if it fails.

While routing over tunnels is not much of an issue, I never did really understand how the tunnels operate.  I didn't realize that the tunnels will come up on each side so long as there  is a route to the tunnel destination in the route table.  Without it, the tunnel won't come up on that router but it can be up on the far end side.  This is again where keepalives come in to play to help know if the tunnel is  really working for end to end connectivity.

The place where tunnels don't use the destination to bring up the tunnel is multipoint tunnels.  There is no true destination for them so they can't consult the routing table to bring them up on the hub.  The spokes do have one check.  That is the NHS.  As long as there is a route to it then it will bring up the interface.  Got a feeling that will be part of troubleshooting.  Definitely can see that.

 So my final thing that  I learned from this section and that is CDP.  No, not actually learning CDP but learning that it is disabled by default on mGRE tunnel interfaces.  Again, a quick troubleshooting problem.

 Again, a nice place to start.  Now I am working on RIPv2.  Hard to know which I like more, that or ODR.  ODR is so easy.  Also I included a pic of my GNS3 topology.  Nothing special there.