HI,
Can a distribuite-list on a stub eigrp router work as a leak-map feature?
Thanks
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
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.
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
Thanks Lazarus much appreciated 
1 Like
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
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
Hi Laz,
Thanks for the feedback 
Martin
1 Like
I have got this topology and I am confused with the last two tasks in task 3 where we have to summarise the routes and we have to make sure only some routers get the summarized route. I didnât understand that what will happen with the intermediate routers if certain routers getting the routes only.
Hello Speedosuper111
The purpose of the last two tasks has to do with the application of summarization, and especially, learning where you should apply this summarization to achieve the requirements.
In the first one, it asks you to summarize the loopbacks of R6 in such a way that only R2 and R1 should have the summarized route of 6.1.0.0/20 in their routing table.
That means that R2 should only receive a single summarized route and not the individual routes. R2 in turn will then relay that summarized route to R1. So the key question is how do I apply summarization so that R2 will only receive the summary route? The answer is, apply summarization on the interfaces facing R2. Specifically, the interfaces of R3 and R4 that face R2. On both of these interfaces you must apply the following config (assuming Gi0/0 faces R2 in both cases):
interface GigabitEthernet0/0
ip summary-address eigrp 12345 6.1.0.0 255.255.240.0
The second task asks for something slightly different. Summarize the loopback of R1 in such a way that only R6 should have summarized route of 1.1.0.0/20 in its routing table. That means that summarization should be applied on the interfaces that face R6. Since itâs only R6 weâre concerned about here, there is only one interface facing R6, and thatâs the interface on R5. So on that interface, you must apply the following command (again, assuming Gi0/0 is facing R6):
interface GigabitEthernet0/0
ip summary-address eigrp 12345 1.1.0.0 255.255.240.0
The intermediate routers will still get the full specific routes, but will only advertise the summary routes at the locations we specified, fulfilling the requirements of the task.
I hope this has been helpful!
Laz
Itâs very helpful. I hope I can get your help with some topologies like this.
1 Like
I need a solution ASAP. I dontâ know how to solve task 7 because it requires to use prefix list and distribute list on a same inerface which we have already put a access list on task 6 so please help me with task 6 and 7.
Hello Speedosuper111
Yes, I understand the conflict. Because youâve already created a distribute list in task 6, you canât create another one in task 7 because the second distribute list command overwrites the first.
In order to get this to work, you will need to combine the ACL/distribute list in task 6 with the prefix-list/distribute list in task 7 using a route-map that references both filters.
At a high level,
- you create the access list as needed for task 6
- you then create the prefix lists needed for task 7
- Then you create a route map that will
a) match ip address in the ACL
b) match ip address in the prefix list - and then, apply the route map to a single distribute list command
That way both will be applied using the same distribute list. Make sense? This should be enough to get you to the right solution. Let us know how you get along!
I hope this has been helpful!
Laz
Yeah, I did exactly that and it worked just fine but I am not certain about how route map permit/deny statements work. I permit in the route map for an access list which first denies the 6.1.4.0/22 network and then permit any and due to this route map didnât work at all, then I used the permit statement in the access list and deny in the route map and it worked???
Hello Speedosuper111
When applying a route-map with a distribute-list, you donât need to focus on using permit or deny statements inside the access list or prefix list itself. Those simply define which prefixes are matched. Whatâs important is how the route-map interprets those matches. In this context, the route-map acts as a matching mechanism that identifies specific EIGRP updates based on your ACLs or prefix lists. The permit and deny actions within the route-map determine what happens to those matched routes:
- if the route-map sequence is set to permit, the matched routes are allowed into the routing table
- if itâs set to deny, the matched routes are filtered out.
- Routes that donât match any sequence are implicitly denied, similar to how ACLs work.
So, in your case, when you used a permit statement in the ACL and a deny statement in the route-map, the configuration worked because the ACL defined which prefixes to match, and the route-map told EIGRP to block those specific prefixes from being installed. Essentially, the ACL or prefix list identifies the routes, while the route-mapâs permit or deny determines whether those identified routes are allowed or filtered.
I hope this has been helpful!
Laz