08-26-2011 06:10 PM - edited 03-04-2019 01:25 PM
I am having an issue with distribute-lists and EIGRP. I have around 12 routes in this test lab with GN3
all belonging to the same AS EIGRP 100. On R11, I created 4 loopback addresses 1.1.1.1, 2.2.2.2,
3.3.3.3, and 4.4.4.4. I advertised them into EIGRP using the network command. I have the following
configuration for my distribute-list. Basically I'm trying to filter out the loopback addresses.
R11
------
int lo1
ip address 1.1.1.1 255.255.255.255
int lo2
ip address 2.2.2.2 255.255.255.255
int lo3
ip address 3.3.3.3 255.255.255.255
int lo4
ip address 4.4.4.4 255.255.255.255
access-list 1 deny 1.1.1.1 0.0.0.0
access-list 1 deny 2.2.2.2 0.0.0.0
access-list 1 deny 3.3.3.3 0.0.0.0
access-list 1 deny 4.4.4.4 0.0.0.0
access-list 1 permiy any
router eigrp 100
distribute-list 1 out s1/2
For whatever reason, routers down stream continu to have those 4 specific routes.
Anyone have any ideas?
Solved! Go to Solution.
08-27-2011 01:01 PM
John,
Now it's clear You have the auto-summarization turned on. It converts your x.x.x.x/32 networks into x.0.0.0/8 as they are all from Class-A ranges, and hence, the distribute list does not apply because it matches on x.x.x.x instead of x.0.0.0 networks.
Either change your ACL, or deactivate the auto-summary on R11.
Best regards,
Peter
08-26-2011 06:23 PM
I tried here with 2 routers p2p and it worked as advertised. Can those routes be learned via other interfaces from R11?
You are only blocking the egress on S1/2 - if you have other interfaces running EIGRP, those routes will be advertised.
08-26-2011 07:01 PM
Maybe it's just a GN3 issue. That egress interface s1/2 is the only interface connected to another router so
yes it's p2p basically.
08-27-2011 01:55 AM
John,
I agree with Edison. It can hardly be a GNS3 issue. It does not influence internal processes within IOS images. There must be something strange going on.
Have you seen the EIGRP adjacency being refreshed or reestablished after you used that distribute-list? A logging message should have appeared on both router telling about EIGRP resync. If not, the distribute list was not even applied. Is it possible you have put the distribute list inadvertently in another EIGRP process?
Perhaps it would help if you posted the snapshot of your GNS3 window to see the topology, and the complete config of both your routers.
Best regards,
Peter
08-27-2011 06:38 AM
Agree with Peter, it's not GNS3 as I did my test with GNS3
08-27-2011 08:15 AM
All the routers are in as 100. And yes i did see the sync msg. The router with the distribute list
Only has one neighbor on a p2p.
08-27-2011 08:31 AM
John,
I see. Well, as I written before: Perhaps it would help if you posted the snapshot of your GNS3 window to see the topology, and the complete config of both your routers, plus the output of show ip route from both routers. Make sure that it is exactly the configuration that is not working.
Best regards,
Peter
08-27-2011 11:38 AM
Thanks guys for all the advise so far. Sorry I have been late getting the picture of the topology I was
out fishing during my last post.
08-27-2011 12:35 PM
John,
Thank you. If I am correct you are performing this experiment between R11 and R4, right? Can I kindly request you for the remaining information I asked for in the previous post: the complete config of both your routers, plus the output of show ip route from both routers? Make sure that it is exactly the configuration that is not working.
Best regards,
Peter
08-27-2011 12:54 PM
R11
---
router eigrp 100
network 1.1.1.1 0.0.0.0
network 2.2.2.2 0.0.0.0
network 3.3.3.3 0.0.0.0
network 4.4.4.4 0.0.0.0
network 192.168.2.0
distribute-list 1 out Serial1/1
auto-summary
!
!
!
no ip http server
no ip http secure-server
!
access-list 1 deny 1.1.1.1
access-list 1 deny 2.2.2.2
access-list 1 deny 3.3.3.3
access-list 1 deny 4.4.4.4
access-list 1 permit any
R9
--
router eigrp 100
passive-interface default
no passive-interface Serial1/2
network 10.0.0.0
auto-summary
R9#show ip route eigrp
D 1.0.0.0/8 [90/4345856] via 10.10.10.9, 00:05:24, Serial1/2
D 2.0.0.0/8 [90/4345856] via 10.10.10.9, 00:05:21, Serial1/2
100.0.0.0/29 is subnetted, 1 subnets
D 100.100.100.0 [90/3705856] via 10.10.10.9, 00:07:47, Serial1/2
D 3.0.0.0/8 [90/4345856] via 10.10.10.9, 00:05:18, Serial1/2
D 4.0.0.0/8 [90/4345856] via 10.10.10.9, 00:05:14, Serial1/2
172.16.0.0/30 is subnetted, 2 subnets
D 172.16.1.4 [90/4729856] via 10.10.10.9, 00:07:42, Serial1/2
D 172.16.1.0 [90/4217856] via 10.10.10.9, 00:07:43, Serial1/2
10.0.0.0/30 is subnetted, 3 subnets
D 10.10.10.0 [90/3193856] via 10.10.10.9, 00:07:47, Serial1/2
D 10.10.10.4 [90/2681856] via 10.10.10.9, 00:07:47, Serial1/2
D 192.168.1.0/24 [90/4217856] via 10.10.10.9, 00:07:43, Serial1/2
D 192.168.2.0/24 [90/4217856] via 10.10.10.9, 00:07:43, Serial1/2
08-27-2011 01:01 PM
John,
Now it's clear You have the auto-summarization turned on. It converts your x.x.x.x/32 networks into x.0.0.0/8 as they are all from Class-A ranges, and hence, the distribute list does not apply because it matches on x.x.x.x instead of x.0.0.0 networks.
Either change your ACL, or deactivate the auto-summary on R11.
Best regards,
Peter
08-27-2011 01:03 PM
I concur with Peter, why do you have auto-summary turned on in the first place?
08-27-2011 01:11 PM
I realize what happend now. I was messing around with auto-summary earlier and did a copy run start on all
my routers and forgot to turn auto-summary off after I saved the config. When I set up this test lab the first
time I had auto-summary turned off. I can't believe I didn't catch that.
08-27-2011 01:24 PM
John,
You are welcome - we are glad to have helped.
One favor to ask from you: in future, please post the topology exhibit, the complete configurations and show command outputs along with your first post. If we saw your topology, the complete configuration and the show ip route command output right in your opening post, we would be able to answer immediately, as this was quite an obvious typo. Here, we had to go over more than 10 posts to "pull out" the relevant output from you.
As a rule, it is better to provide more info than necessary when debugging a problem than to post "just the relevant snippets" of the config. Abundance of information is seldom a problem when debugging; the lack of information always is.
Best regards,
Peter
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide