For example, an Internet Service Provider might want to filter incoming updates received from the customers to ensure they’re not advertising transit routes and advertise only IP prefixes they actually own. Inbound route maps might also be needed to attach BGP communities to inbound routes or set BGP attributes (for example, local preference) based on communities attached to incoming routing updates.
You can perform all these tasks with route-maps, but then you’d probably have to create a dedicated route-map for each customer (as the inbound prefix filter has to be customer-specific). Changing your routing policies or community definitions would require changing a lot of route maps.
Update [email protected]:39: distribute lists and prefix lists can't coexist (they cannot be configured in the same direction on the same neighbor)On the other hand, if you use all the filters available in the BGP routing process, you could:
- Use neighbor filter-list in to check the customer-specific AS path requirements;
- Use neighbor prefix-list in to filter customer prefixes, reject too long prefixes or prefixes not belonging to the customer;
- Use neighbor route-map in to drop prefixes belonging to your own address space, implement various routing policies and set BGP communities.
The solution scales even better if you configure common filters (route-map in and filter-list in in our scenario) in a BGP peer session template.