How to Filter Prefixes with Distribute-list

Lessons Discussion
21

HI,

Can a distribuite-list on a stub eigrp router work as a leak-map feature?

Thanks

22

Hello Giovanni

A leak-map in EIGRP is specifically configured using the leak-map keyword as part of the ip summary-address command as described in the following lesson:

Can you give us an example of what you had in mind when you considered a distribute-list as a leak-map feature? Provide a sample topology so that we can further discuss it…

I hope this has been helpful!

Laz

23

Hi,
Does anyone know if its possible to filter default gateways when redistributing between different EIGRP Autonomous systems ? I tested it in a GNS3 lab and to my surprise it seemed to work but I’m wondering is there a definitive proven way to do this.
I need to put this into production.

The issue is I have a network in two different cities. Lets say city A is running EIGRP AS 100 and city B is running Eigrp AS 200.
AS 100 has its own local default gateway pointing to a firewall and similarily AS 200 has its own local default gateway pointing to its local firewall.

I want to “merge” the AS 100 and AS 200 together by redistributing between each other on a single switch and this is all good and easy but I dont want each AS to know about the others default gateway so they will still use the correct one.

Has anyone any experience of this and am I overlooking anything ? as i mentioned when I labbed it up it seemed to work as expected first try.

Thanks.

24

Hello Sean

Your description and design approach is sound. I have not personally had experience with this specific arrangement, however, it is standard procedure, even to filter out default routes.

EIGRP allows you to filter using various methods, including distribute list filtering, prefix list filtering, as well as using route maps.

Because your particular filtering is simple (i.e. it’s just one statement), you can use any of these methods to achieve what you need. And since you’ve done your due diligence and simulated it and everything is working fine, you should be good to go to implement it in your production network. Let us know the results when you implement it!

I hope this has been helpful!

Laz

1 Like
25

Thanks Lazarus much appreciated :+1:

1 Like
26

Hi Team,

This type of filtering seems very impacting, sometimes during the configuration of R1, R2 is starved out of its RIB.

In the examples where we have the route-map applied, how can we add/delete/re-order sequence numbers without impacting the current state?

My VM router is running Version 12.4(24)T8, and it seems like I cannot play with the sequences.

In the real world, how to minimize this impact?

Kind Regards.
Martin

27

Hello Martin

You can add, delete, or reorder sequence numbers in a route-map without impacting the current state by using the sequence numbers that Cisco IOS allocates to individual statements within a route-map. By default, Cisco IOS assigns sequence numbers in increments of 10, so you can insert new statements between existing ones without having to redo the entire configuration.

To add a sequence, you simply specify a new number with the route-map command. For example, if you have sequences 10 and 20, you can add sequence 15 with the command route-map MAP_NAME permit 15.

To delete a sequence, use the no form of the route-map command, like no route-map MAP_NAME permit 10.

To reorder, you’ll have to remove and re-add the sequences in the order you want them. This can be a bit disruptive but if you prepare the commands beforehand, you can paste them in quickly to minimize the impact.

Remember, changes to route-maps take effect immediately as you enter them. So, it’s a good idea to make these changes during a maintenance window if possible.

As for your VM router running Version 12.4(24)T8, you should be able to manipulate sequence numbers. If you can’t, it might be a bug or limitation of the virtual platform you’re using.

To minimize impact, changes on production networks are generally made during scheduled maintenance windows and are thoroughly tested in a lab environment before being implemented in a live network. Thus possible mistakes are caught beforehand, and the impact on the network is minimized.

I hope this has been helpful!

Laz

1 Like
28

Hi Laz,

Thanks for the feedback :slight_smile:

Martin

1 Like