route-map

I doubt anything. If there is no match statement that references an access-list, then even if a routing protocol was using the route-map, there are no addresses to match on and therefore prioritize. I would presume it was a legacy statement for BGP preference setting w/ your ISP(s)? Probably had an access-list w/ networks/masks to prioritize one ISP over the other or something, along with prepends? Just guessing, but I don't think it can do anything without a match statement. Else someone else on here will surely speak up.

It isn't doing anything that I know of. Do a:

show run | i route-map ISP-IN

If the only match you get is the route-map itself, then it isn't applied to anything and you might as well delete it.

It could be some kind of hack or workaround for a crappy IOS, but I'm not familiar with it.

Interesting, although he never confirmed that he did have it applied on any neighbor statement. I'm still not sure why you would have a map to adjust basically nothing on everything (all routes). Still seems like a legacy statement left in or something not fully implemented that nobody every fixed or questioned.

Yes, and I definitely appreciate you clearing that up for me. Out of experience, I would have ripped it off the neighbor statement first and then cleared the actual map (can't think of a single instance where this isn't the best thing to do except when just replacing an ACL or map), but definitely a good thing to keep in the back of my mind going forward. I don't think I would have expected that to be the way it is, as usually networking software is not assumption-based, as it seems in this case.

In the absence of any match clauses, the route-map entry matches everything, yes? Documentation says that "all" match clauses must match. If there are no match clauses, that condition is vacuously satisfied. That means that this route-map matches all traffic.

However, if the route-map were removed, I assume that the resulting configuration would match no traffic.

Or it could simply be a filter on which ISP routes to accept.

e.g.

route-map ISP-IN permit 10

router bgp 12345 ... neighbor isp.address.goes.here route-map ISP-IN in ...

As things stand, he gets all ISP routes. Delete the route-map and he gets no ISP routes. Delete the neighbor clause and he gets all ISP routes.

If he _wants_ to filter ISP-learned routes then the right move is to populate the route-map with match clauses using prefix-lists, access lists, AS-paths or similar.

If he just wants to clean up the config then he should remove the neighbor clause and then remove the route map. And then he should reset the ISP peering session and make sure that things still work as expected. (clear ip bgp isp.address.goes.here soft in)

Agreed on both counts. He never indicated whether the route-map was actually referred to elsewhere in the configuration. And the route-map is most likely either either left-over cruft or not-fully-implemented cruft.

The key point that I'd hoped to make was that even though this route-map doesn't _do_ much, deleting it could have nasty consequences if it is still referred to and if one didn't clean up those dangling references first.

Clearly if it is not referred to then it is not doing anything and can be safely removed.

It might be a placeholder. In a large network, it's common to have configuration templates. So perhaps every machine is required to have this route-map, but the content varies by machine, and it can be empty if nothing needs to be put in it.