I have quite a few questions about the configs that you posted. If we can get some of them resolved it may help us get closer to the solution.
first a picky objection: the file labled HQ router has comments that identify it as Remote Site Router and Remote Site Switch. Looking at configs with misleading comments makes the process more complicated than it should be.
I notice that the serial interface on both HQ and remote has the parameter no keepalive. I wonder why that is. With no keepalive configured the interface will never go protocol down. And this means that any static route pointed at this interface will never be withdrawn from the routing table.
According to the drawing the tunnel to the remote should be IP address 10.10.1.58 but that address does not show up anywhere in the remote config that you posted. The remote does have a tunnel but its address is 10.10.1.54/30. So is the remote communicating with HQ? If so how?
I notice that the tunnel at HQ is shutdown. Why is this? Does this mean that the only communication from HQ to the remote is via MPLS?
I am puzzled about this statement: The floating static is not supposed to take over unitl the interface is down. Actually the floating static taking over has less to do with the interface going down (which it will never do as I commented above) and is actually dependent on the advertised route being withdrawn from the routing table. I can not tell from your description whether this is what is happening or not.
Perhaps you can clarify the parts of the situation that I have pointed out and can clarify what is happening with the floating static routes.
Ok, I will try and answer your questions as accurately as I can, keep in mind, that is why I am asking questions. Because I don't know the answers. This is why I am posting questions on this forum, to learn.
As far as the file being labeled HQ router, I put the comment in the post that it is both the HQ router and HQ switch. I spaced the two files thinnking it would be obvious to an experienced person the two configs were on there. If it is not, then I apologize for any confusion and I can resend them in a differnet format.
The serial interfaces are configured with no keepalive, because when I first put the routers back to back, the connection did not come up. I discovered that one of the routers was configured with no keepalive on the serial interface, so I just configured the other one the same. I do not have enough experience or knowledge to know that:
"With no keepalive configured the interface will never go protocol down. And this means that any static route pointed at this interface will never be withdrawn from the routing table."
The drawing is showing the setup in production, it is not the test setup. There are two tunnels configured, one for each switch. In the test setup, I only used one tunnel, it must have been the other one that is shown in the drawing.
In the config I sent that shows the tunnel shutdown, I must have copied the config after I had shut down the interface for some reason.
As far as you being puzzled about the statement I made, I have mentioned numerous times that I am not very experienced. This why I am asking the questions I ask. If they are puzzling or do not make sense, try to rememberlong before you got to where you are now. That is where I am. I am asking because I do not know the answers and I am making statements that probably are incorrect or patially incorrect.
If there is a good book about practical routing or that would be a good substitute for asking the questions here, I am all ears.
I think that you are not reading my posts carefully again. Here is the first line from the file labeled as HQ router:
Remote Site Router
My point does not have anything to do with whether there are two configs in the file or not. It has to do with the identifying comment being absolutely backward!
Since your question seems to focus on floating static routes and interfaces being up or not I think it is important to clear up the issue about keepalive. As I stated with the serial interface configured with no keepalive the interface will never go to state protocol down. So what happens if you configure all the serial interfaces with keepalive enabled? If they work then we can proceed to look at the rest of your issue. If they do not work with keepalive enabled then you have some other connectivity issue that we need to solve.
"The floating static is not supposed to take over unitl the interface is down, but it works in my lab."
The route, which we'll call a 'floating' route, has nothing directly to do with interfaces being up or down. It is a route that the router considers when deciding what information should go into the route table.
Richard, do you know about 'administrative distance' in routers. The rules about when a floating route appears in the route table are related to administrative distance not interface state.
If you have a routing protocol or some other source of routing information for a particular prefix (destination) and you add a static route with high AD to the same destination, the router has to decide which information goes into the route table. He does this (as you would know) by comparing the administrative distance. It has nothing to do with interface status.
So, your floating static is active becuase there is no better route to the destination currently on the router.
My main concern is the MPLS and OSPF processes and the fact that I didn't know exactly what would happen if the interface stays up and OSPF connection is broken. I made a comment in the prior post that was not accurate.
Basicly, I just wanted to know if the concept was ok,
Which is, GRE tunnel to Main site via Internet, static routes with AD of 150 to main site thru tunnels.
The primary connection to main site is with OSPF thru MPLS cloud. The default gateway is distributed to remote sites with OSPF.
If the routes die and interfaces stay up, then the static routes will take over thru VPN, until the OSPF process is back up.
The ProblemEnter EVCsHow It Works (Ingress)How It Works
(Egress)Step-by-Step ExampleFinal Thoughts The ProblemOn traditional
switches whenever we have a trunk interface we use the VLAN tag to
demultiplex the VLANs. The switch needs to determine which MAC ...
The ProblemEnter EVCsHow It Works (Ingress)How It Works
(Egress)Step-by-Step ExampleFinal Thoughts Introduction: Netdr is a tool
available on a RSP720, Sup720 or Sup32 that allows one to capture
packets on the RP or SP inband. The netdr command can be use...
IntroductionOSPF, being a link-state protocol, allows for every router
in the network to know of every link and OSPF speaker in the entire
network. From this picture each router independently runs the Shortest
Path First (SPF) algorithm to determine the b...