How to block an OSPF learnt route

[Jan Gilhooley]

I've never had to consider this before - but we are migrating remote sites from one network provider to another whilst retaining the same IP address schemes on the sites.  We now have the situation where the new providers work around for handling the 2 routes being advertised to our core doesn't work (turns out a bug in a certain class of non-Cisco router), so whilst I wait for the old provider to remove the routes I quickly need a "Plan B". 

So what I need is to prevent our main router OSPF learning the old provider's route for specific IP ranges. From some googling I think this would work as planned. But as I have never done this before I would like some feedback.

access-list 50 remark Block Old Supplier Routes
access-list 50 deny 10.10.1.0 0.0.0.255
access-list 50 deny 192.168.1.0 0.0.0.255
access-list 50 permit any

router ospf 10
distribute-list 50 in GigabitEthernet0/1

As I understand it the ACL (50) would only be applied to inbound learnt routes only on interface Gi0/1. The same routes learnt from elsewhere (i.e.the new supplier) would populate our routing tables in the normal way.  And of course all routes learnt from the new supplier would be unaffected.

I know I can use route-maps and all kind of wonderful things - I just want a simple, quick, and safe solution to a temporary problem! 

Thank you

[Joseph W. Doherty]

Yes, the "distribute-list in", with OSPF, should suppress those route prefixes, as you desire on that router's route table. A possible problem, though, might be that router will still advertise those route prefixes to other OSPF neighbors.

E.g.: https://networklessons.com/ospf/ospf-distribute-list-filtering

However, if the topology is such that other routers will forward the traffic to the router suppressing the "bad" route prefixes, especially if it has the other "good" route prefixes, you should be okay.

[Joseph W. Doherty]

I guess I should add, that since other OSPF routers might "prefer" the "bad" over the "good" route prefix, you can also cause a routing loop. Again, much will depend on you topology. If the egress router is the "final" transit router, then it having just the "good" route prefixes should keep in all okay.

[Giuseppe Larosa]

Hello @Jan Gilhooley ,

OSPF is a link state protocol so you would need to apply the same distribute list on all routers otherwise routers downstream the core router will still receive the LSAs for the filtered routes and will install them causing a routing black hole.

In short terms route filtering with distribute list does not change the LSA flooding within an OSPF area.

You can consider to move the older provider to a different area, but this can be a challenge too.

The only device that can perform a granular route filtering is an ABR between area 0 the backbone and a non backbone area and only  for internal routes.

Edit:

I think that Joseph's answer is correct if the core device is on the path in any case there is no risk of blackholing and the use of a distribute list can be considered a viable option.

Hope to help

Giuseppe

[Jan Gilhooley]

Thanks for the responses - I will read and digest them in more detail later. We actually gave it a go earlier with our supplier.
Our first thing was a suggestion a colleague made of changing the old suppliers ospf cost to something higher (ip ospf cost 100) on the router interfaces - so if there were 2 routes to the same /24 destination the new supplier would be the more attractive route. This didn't work and as soon as the supplier workaround was removed and a /24 was advertised to us the old supplier route was still preferred.

We then tried what I posted above - this kind of worked - but it seemed to block all the routes, not just the one learnt from the legacy interface. Certainly we couldn't see the routes advertised to us. So we reverted back and will consider our next moves carefully.
The obvious is to ask for the old routes to be ceased since we don't need them anymore - but that carries a (small) cost and a 10 day lead time - so a good couple of weeks to make the change (and what we actually want to do is completely cease the old circuit, not change it). I was just hoping for a quick "make the new /24 route more preferable to the old /24 route" so we dont have issues in the meantime :-)

[Joseph W. Doherty]

Other options you might consider, using a different OSPF process for the "bad" route prefixes or using a VRF.

[Joseph W. Doherty]

Since both Rick and Giuseppe also suggest using a separate OSPF process, that alone, on the router doing it, might not be sufficient. What you may also need to do is to cost the links to the "bad" route prefixes worst than the "good" route prefixes. This because, on that router, even though the other OSPF process won't know about the "bad" route prefixes, unless you redistribute them, that router will still have both in its common route table (again, on that router). I.e. traffic on that router may still prefer the "bad" route prefixes. However, if you use VRFs, you also have separate route tables, so then the issue is "leaking" route prefixes from one VRF to the other. I.e. by default, traffic won't intermix between the VRFs.

BTW, earlier I had thought to also mention just OSPF costing the links to the "bad" provider higher, but forgot to mention it when I wrote my earlier post. Ignoring your original question about using distribute list with OSPF, costing would seem to be the simplest approach. As Rick noted, we don't really have a good idea of your overall topology, but are you sure you costed the interfaces, to your "bad" provider high enough to insure the "bad" route prefixes do not show in the route tables? Also, though, keep in mind, when you cost the interfaces to your "bad" provider, all OSPF routes from that provider will be adjusted. Might that have been the issue when you tried it?

[Martin L]

not sure about this migration; Remote site A is going over the old ISP while Site B is over new provider Or part site A is going over old one while other part of A going over new provider? 

1. My idea is that All Remote sites should be in other Areas while main HQ is area 0. Then you could filter on Type 3 LSAs.  Since OSPF prefers internal over external routes anyway, filtering may not be needed.

2. Another idea is to run 2 OSPF processes and redistribute them accordingly.  i.e. router ospf 1 and router ospf 2 on same router

3. Alternatively,  making Remote Site to run different protocol and redistribute routes. 

let me know if Any of those ideas are "out there" and "too much"

Regards, ML
**Please Rate All Helpful Responses **

[Richard Burts]

There are aspects of this environment that we don't know and that impacts our ability to give good advice. In particular it would be helpful to know how the main router learns routes from the providers. Am I correct in assuming that the main router learns routes running OSPF directly with both providers? If not please provide clarification for how main router learns routes from providers. 

If if so I will suggest a solution. First a bit of background. As several of my colleagues have discussed OSPF is a link state protocol. And as such all routers within an area must have equivalent Link State Data Base. Because of this a distribute list can prevent a route from being put into the local routing table but can not prevent advertising of that route to neighbors. The best way to filter route advertisements is to filter route redistribution. So my suggestion is this:

- modify the existing OSPF configuration to remove the network statement for the interface connecting to the old provider. 

- create a new OSPF process (if existing OSPF is 1 then create router Ospf 2)

- add a network statement for the interface connecting to old provider. 

- in the existing OSPF process configure redistribution from the new OSPF process with a route map or distribute list. This will allow you to advertise the routes that you want from the old provider and suppress the routes you don't want. 

Having worked out this logic I realized that there is a flaw in my suggestion. Why does it matter what your main router advertises inside your network? As long as your inside network forwards to the main router it should be able to forward to the correct next hop based on the distribute list. If that is not working we need better information about your main router and its routing table. 

[Giuseppe Larosa]

Hello @Richard Burts ,

I think your suggestion may be the correct solution to use a separate OSPF process.

Reviewing the thread and the feedack provided by original poster @Jan Gilhooley the big drawback of distribute-list in in OSPF is that is not able to support a specific input interface but it applies to all incoming interfaces. If this happens all denied routes are simply not reachable anymore by the main core router with no distinction between old provider and new provider links.

Alternatively, the OSPF costs on the links to old ISP could be manipulated to make them less attractive then those of the new provider . This should be done also on each remote site for the opposite direction of traffic to the HQ.

Hope to help

Giuseppe

[WaleedMohammed64478]

I am having lots of issues getting this to work.

[Richard Burts]

The original post asked about an issue trying to filter OSPF learned routes and my response focused on the issue filtering routes. I believe that 2 processes with redistribution is an appropriate solution for that. But as I read the thread I believe that filtering may not be required. If I understand correctly the issue is that in a transition period that both providers are advertising the routes for a remote office being moved over. It doesn't matter what the main router advertises to inside resources. It only matters that when both providers are advertising the same office network that the main router chooses the route from the new provider. It seems an appropriately high cost on interface for old provider should accomplish this.