Redistribution/Route Filtering

dtrujillo63

I'm currently messing around with redistribution and route filtering, but I have a few questions. What's the preferred way to route filter? I found at least 4 different ways to accomplish the same thing.

1. filter right from the redistribution command using a route map
redistribute ospf 1 route-map rmap1

2. filter using the distribution-list command using a route map
distribute-list route-map rmap1 out ospf 1

3. filter using the distribution-list command using an ACL
distribute-list acl1 out ospf 1

4. filter using the distribution-list command using a prefix-list
distribute-list prefix plist1 out ospf 1

Is there a "best practice" way to route filtering?

networker050184

Which ever one you feel the most comfrtable and is the simplest solution is the way I usualy go. Prefix-lists are great for filtering certain ranges of addresses that you can't really do with an ACL. Route-maps allow you to have multiple match and deny statements with differing actions on multiple match criteria. Keep in mind the implications of distribute-lists on OSPF and their placement.


My prefered way is always route-maps with prefix-lists for filtering whenever possible. Allows for the most flexibility.

danb83

I have been searching for some clarity on route filtering, as I'm struggling to understand the concepts from reading the Cisco Press book.

Are the below valid options for Redistribution Filtering?

1) Distribute-list command - can reference an ACL or Prefix-list
2) Route Map (using redistribute command) - can reference an ACL or Prefix-list

So in summary, you define an ACL or Prefix-list to filter/permit the required routes, and apply this through either the Distribute command or a Route map?

Networker - you said above route maps offer more flexibility? This does include giving the ability to set the metric for chosen routes?

thanks

james43026

I'll throw in what I know.

1.) This command can reference an ACL, a prefix list, or a route map
2.) Yes a route map can reference either, it can also match on a large array of other material as well.

You apply your filtering through either a distribution list, or through a redistribution statement. You have to remember that an ACL, route map, or prefix list, are simply a way to pick the interesting traffic that you want to impose filtering and or changes to, and they all need to be applied using another mechanism. The distribution list and redistribution statement provide that mechanism. It's similar to how you create an ACL to filter some sort of traffic by permitting it or denying it, well once you create an ACL it does nothing if you can't apply it to an interface, so you apply the ACL to an interface using the ip access group command. The same goes for a distribution list and redistribution, you apply it through the routing process.

Yes, a route map would give you the ability to set the metric for routes as well, you could also set the metric type, for say OSPF, if the routes were external, and you wanted a route to be a type 1 external, instead of the default type 2 external. There are a lot of other things you could do as well. I imagine using a distribution list that references a route map, which in turn references a prefix list would provide an enormous amount of flexibility.

danb83

Thanks for the reply, that's a useful explanation that the Press book lacks.

Makes sense when comparing to ACLs (first create & then apply)

Create filtering:
ACL / Prefix-list / Route-map

Apply filtering:
Distribution Lists / Redistribution statements

hurricane1091

I prefer to redistribute with route maps matching an ACL. That's what we do at work and it seems the most simple. I don't know, it just seems to be the easiest.

You redistribute one routing protocol under another routing protocol's config mode, pointing to a route map. That route map points to an ACL and also sets the metric. The ACL then identifies the traffic. It just seems like a logical flow. Or I guess using a prefix list instead of an ACL is essentially the same thing.

It would seem odd to me to redistribute an entire routing protocol, then initiate a distribute-list command for filtering. If you mistype something somewhere and accidentally leak more routes than you wanted, that's probably riskier than having a type on a redistribute command and referencing a non-existent route map.

james43026

Hurricane, I also prefer to do my first layer of filtering in the redistribute command. But if you happen to have a need to prevent redistributed routes, or any routes for the matter from reaching a specific router, or OSPF area, or whatever it may be. You could then filter routes that are either being received or sent by a router, you can even filter based on interfaces with a distribution list. Lets say you have a subnet in your OSPF backbone that you want to have full connectivity from within your backbone, but you don't want this subnet communicating with any other areas, you could apply inbound distribution lists on all of the ABR's and their interfaces connected to the backbone, thus meeting your requirements. Same could be applied to an ASBR that is connected to lets say the backbone, and there are networks that you want to redistribute into your backbone, which has lets say area 1 and area 2 connected to it, lets say you want to these redistributed routes to flow into area 1, but not area 2, you could apply a distribution list inbound on the area 2 ABR inbound, thus preventing the area 2 ABR from ever learning about the routes.

mistabrumley89

networker050184 wrote: »

My prefered way is always route-maps with prefix-lists for filtering whenever possible. Allows for the most flexibility.

I'd have to agree with this setup.

hurricane1091

james43026 wrote: »

Hurricane, I also prefer to do my first layer of filtering in the redistribute command. But if you happen to have a need to prevent redistributed routes, or any routes for the matter from reaching a specific router, or OSPF area, or whatever it may be. You could then filter routes that are either being received or sent by a router, you can even filter based on interfaces with a distribution list. Lets say you have a subnet in your OSPF backbone that you want to have full connectivity from within your backbone, but you don't want this subnet communicating with any other areas, you could apply inbound distribution lists on all of the ABR's and their interfaces connected to the backbone, thus meeting your requirements. Same could be applied to an ASBR that is connected to lets say the backbone, and there are networks that you want to redistribute into your backbone, which has lets say area 1 and area 2 connected to it, lets say you want to these redistributed routes to flow into area 1, but not area 2, you could apply a distribution list inbound on the area 2 ABR inbound, thus preventing the area 2 ABR from ever learning about the routes.

I can see what you are saying and see scenarios where that could be desirable. Every network is different. For us, we do not need to do it though which I guess is why I prefer the method that I do. All BGP routes learned via MPLS from all the satellite offices for example we want redistributed into our IGP all the way back to the core. Additionally, we want all routes sent out to the branches. On another note, those branches do not get a default route because we utilize a different IGP over the backup circuits at branches, and want that route to appear in the routing table when an MPLS circuit goes down at a branch. And with this DMVPN re-design I am working on a strategy to implement, that is totally desirable.

I did have an OSPF lab though where I messed with preventing certain areas from learning routes that others would learn. It got crazy lol. OSPF can be quite the animal, glad we use it in a simple manner lol.