cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2810
Views
5
Helpful
13
Replies

EIGRP Distribute-List Issue

JohnTylerPearce
Level 7
Level 7

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?

1 Accepted Solution

Accepted Solutions

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

View solution in original post

13 Replies 13

Edison Ortiz
Hall of Fame
Hall of Fame

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.

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.

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

Agree with Peter, it's not GNS3 as I did my test with GNS3

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.

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

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.

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

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

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

I concur with Peter, why do you have auto-summary turned on in the first place?

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.

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

Review Cisco Networking for a $25 gift card