How is the route getting in?

[richmorrow624]

We have the following situation:

HQ site has 2811 pointing into MPLS cloud connected to a 4300 series switch via ethernet on the same subnet. This connects remote branches to HQ site.

The router is running ospf and rip, the switch is running rip.

The switch is distributing it's static routes into rip.

The router is doing mutual redistribution between the two protocols.

There is a static route in both the router and switch that points to a VPN device to a remote DR site. All these are on the same ethernet subnet.

The ospf routes from the remote DR site are filtered from the HQ site route table.

We recently added an MPLS connection to the remote DR site. The firewall at the remote DR site that connects to the VPN has ip address 10.10.10.1, the router at remote site via mpls has 10.10.10.254.

There is no routing protocol running on the firewall at remote site, so no routes are populated to the router.

The goal is to have HQ site connect to remote via VPN (this works) and have all other remotes connected to MPLS to connect via MPLS cloud. There are static routes in firewall (10.10.10.1)at DR site pointing only MPLS remotes to router ethernet (10.10.10.254)

I have removed the static route in the HQ Router and can see the route to remote in HQ router is populated via rip to VPN device (this should be ok).

Here is the problem, the MPLS remote sites continue to connect via the HQ site.

From the new MPLS site, I can ping other existing MPLS remotes, but from the existing MPLS remotes to the new site, they do not return.

Trace reveals they are still trying to go through HQ site

Why don't the remotes that point into MPLS cloud connect via OSPF with higher AD value?

how are they getting in?

Is it possible I didn't wait long enough for rip routes to remote via vpn to die?

I waited maybe 5 minutes. Each MPLS remote site has a two routers, one that is getting only ospf routes from MPLS, the other has rip and ospf with mutual redistribution. The router redistributing doesn't go anywhere, hust has ethernet connection to MPLS router.

This was implemented by a so called really good consulting firm, but it is a mess I think.

[Richard Burts]

Richard

I have read through your description several times and I still do not understand what you are describing. One part of your description seems to me potentially significant:

The ospf routes from the remote DR site are filtered from the HQ site route table.

Do I understand this to mean that there is a distribute list on the HQ filtering routes so that they do not appear in the routing table? One of the aspects of OSPF is that it does not advertise "routes" but advertises "LSAs" which means that the distribute list which filters "routes" will prevent the route from appearing in the local routing table. But it does not prevent the LSA from being in the OSPF database and does not prevent those LSAs from being advertised to other OSPF neighbors.

If this does not help resolve your issue, then perhaps you could try to clarify the environment and the problem.

HTH

Rick

[richmorrow624]

Sorry for the confusion,but it is very confusing the way it is set up.

You are correct in that at the HQ site, there is a distribute list preventing a route to the DR remote in the HQ router. So, at the HQ site, the only route to the DR site, is in the route table is the static route, unless I remove the static route. Then it is the RIP route that is distributed from the switches, that points the traffic to the VPN device as the next hop.

This is all ok, because I am only concerned that the MPLS remotes get to the DR site via the MPLS cloud.

Ok let me approach it this way, say that I want to make sure I direct the traffic in the cloud differntly than what may be advertised from the HQ site, because I guess what I am describing is that. That the HQ site is letting the route be advertised.

The filter list is "in" on the HQ site serial port which stop the route table from having the route on the HQ router.

What I want is to filter it "out" of the serial to keep it from being advertised?

Im sorry it is late.

Is that correct?

[tdrais]

I think rick's comment is your issue.

If the route is in the HQ site OSPF database even if you suppress its ability to be in the routing table you cannot prevent it from being advertised to another OSPF neighbor.

The all routers in a OSPF domain share a common routing table is a fundemental to OSPF. The distribution filters in OSPF have a very different function that other protocols its just appears that they do the same thing.

Your example is one of the reasons many people use BGP for MPLS. It allows you to have more impact over what the providers routers are doing since BGP has so many options to influence traffic on remote routers.

If you need to have a route suppress in the providers routers you are going to have to ask them to do this. You should be able to tag your routes to make it easier for them to identify which to suppress. Depends on your provider, many do not want to mess with this type of detailed site management.

[Richard Burts]

Richard

Tim correctly explains that one of the concepts of the link state protocols is that they should have a common understanding of the topology and therefore there is very limited ability to filter advertisements between OSPF neighbors (what one OSPF router knows about should be known by all other OSPF routers - especially so for all OSPF routers in that area).

What I believe you are asking is that HQ sees one route to the DR site, HQ should advertise some routes to MPLS routers but should not advertise its routes to the DR site. I have been able to do something similar to this and I believe that you may be able to do it - assuming that the HQ router has an interface used for MPLS that is not used for other connectivity. The way to make this work is to run 2 OSPF processes on the HQ router. One process would run on interfaces to HQ resources and to the DR site and the other OSPF process would run on the interface to MPLS. (The fact that an interface can participate in only one OSPF process is the reason that the interface to MPLS must not carry traffic to HQ or DR.) The advantage of 2 OSPF processes is that you can redistribute between them and you CAN filter the redistribution. So the HQ router can see one path to DR and advertise that path to HQ neighbors (through one process) but will not advertise those routes to MPLS neighbors (through the second process).

HTH

Rick

[richmorrow624]

Sorry Rick and Tim,

I did not fully read you knoledgable posts before I wrote my reply.

Basicly what you are saying is that I will need to make major changes to make this work.

Why do you think the 10.10.126.0 route worked?

[Richard Burts]

Richard

I still do not have a good understanding of the environment that you are working in. But I look at this description of what you did about 10.10.126.0"

Since the connectivity cannot be broken for very long, i used 10.10.126.0 as a test case and set that route up exactly like the 10.10.125.0 route.

It is statically added to the switch, I didnt put it in the router, because I removed the 10.10.125.0 from the router.

and I wonder about your statement that you did not put it in the router. Is that the difference that allowed it to work?

HTH

Rick

[richmorrow624]

Im sorry rick,

I know I have confused the heck out of you.

But, I am wondering if you guys were on the right track before. Maybe the user ospf routes are getting in the core route table and causing trouble.

I was thinking about it and is the difference that the 10.10.126.0 interface goes away when I change the IP address? The 10.10.125.0 always stays up?

What I was trying to say ( i think i am not articulating my situation very well) is that the setup was the same, I didn't put the 10.10.126.0 route in the HQ router, because I took out the 10.10.125.0 route when I was trying to get that to work.

So the scenario was the same, except for the fact that the connection was brokien by removing the ip address on the 10.10.126.0 network and not on the 10.10.125.0 network.

I want to try olorunloba's suggestion and take out the redistribution all together and simplify this.

I could also just add a static route to the workstations and servers that need to connect via the HQ site and let OSPF direct the remote site traffic via the cloud.

I really appreciate your helpful replys.

You guys have really helped me think this situation through though, much more than I would have on my own.

[richmorrow624]

Rick,

I don't know if you will get this or not, but I was able to get it to work.

The route was getting in the MPLS cloud by two different sources:

1. By the switches at the HQ site, the static route was distributed into RIP to the HQ router, then the router distributing RIP into MPLS.

2. The HQ switches have tunnel connections to some of the remote sites, with the remote routers running RIP and OSPF with mutual redistribution.

The HQ switches have two VLAN interfaces pointing to the above. I put a distribute list on the outbound VLAN interfaces preventing the 10.10.125.0 subnet from getting replicated into RIP, that in turn prevents it from getting replicated into OSPF.

This solved the problem

[Richard Burts · Accepted solution]

Richard

I did get this update. And I thank you for posting to the forum indicating the solution. It makes the forum much more useful when we can read about a problem and can see what the solution for the problem is.

Your explanation makes sense. One of the very interesting things that has come out in this discussion is the very different behavior of distribute list in the OSPF environment (where it works but not in the way that most people expect) and in environments like RIP where it does what people expect it to do.

HTH

Rick

[richmorrow624]

Thanks for your help Rick.

[richmorrow624]

He is something I did not add last night:

Since the connectivity cannot be broken for very long, i used 10.10.126.0 as a test case and set that route up exactly like the 10.10.125.0 route.

It is statically added to the switch, I didnt put it in the router, because I removed the 10.10.125.0 from the router.

I changed the DR site ethernet address to 10.10.126.0 and everything works. I see the route in the HQ router route table via RIP, ok since I don't care about that because of the static in the switch.

But all of the MPLS sites will use the MPLS path to the DR remote site.

Here is where I get confused hopefully it can be followed:

The static route to the DR site at the HQ site, points to the VPN device. If the switch(only RIP)is set to distribute static and the router (OSPF, RIP)is set for mutual redistribution, it makes sense that I would see the RIP route in the HQ router and not the OSPF because of the

distribute list "in" blocking the route from the table, I do see it in the database.

When I have the DR set to 10.10.125.0, it does not work.

The question is, are there two ospf routes being generated from two different sources (switch static route origin, and remote DR ehternet)and is it a metric issue maybe, or do I totally no understand what is happeneing?