Doing EIGRP lab need some help

[hfakoor222]

Hi doing a EIGRP lab need some help with a couple of questions

However here is the lab topology, the questions are straight forward

first question:

• R4 is low on memory and should not be queried by EIGRP about routes in the active state. Make sure that R4 does not lose it’s role as a redistributor of routes from EIGRP 200.

How do I go about doing this? Not sure how to stop queries about routes, unless I either do passive or stub. In this case I am thinking make R4 a stub, and select stub options from there.

This is 2nd and last question:

R6 and R3 should ignore EIGRP updates from one another but maintain their neighborship. R5, however, should facilitate EIGRP communications between both routers on the LAN segment by ensure R3 and R6 still see one another’s updates, even indirectly.

How do I have R6 and R3 ignore uopdates?

Prefix list

from source address R6/R3 going to EIGRP

multicast address 224.0.0.10

? 

For example R6's interface address on the link is

192.168.3.6

so on R3 I would do:

ip access-list extended R6_Block
deny ip 192.168.3.0 0.0.0.255 host 255.0.0.10
permit ip any any

Is this correct?

Any tips appreciated.

[David Ruess · Accepted solution]

Hello,

To answer your first question yes you would configure EIGRP as a stub router, By default it will only advertise

connected and summary

routes. You can modify this behavior and configure the stub to advertise

connected and redistributed

routes with the following command:

eigrp stub connected redistributed 

under the EIGRP routing process.

For the second question this looks to have several parts. I will try to break down each one

1. You can try using an extended ACL with the

distribute list

to deny updates from a neighbor:

on R3

access-list 105 deny ip host192.168.3.6

any (configure the same on R6 but use R3s interface IP in the ACL)

access-list 105 permit ip any any

Under the router process

distribute-list 105 in f0/1

Using an extended ACL in an EIGRP

distribute-list

configuration has the following affect: The "source" is the neighbor you're trying to filter from, and the "destination" is the route to be filtered.

^I have not tested the above configuration (at the moment). Hopefully it works and I will try to lab when I get a chance.

2. You have R3, R5, and R6 all neighboring with each other on the same broadcast network. You just blocked R3 and R6 from learning each others routes. That means R5 is learning routes from both R3 and R6. However due to an important rule R5 will not advertise any route out the interface it learned it....sound familiar? This is the

split-horizon

rule. You must disable this on

R5's F0/0

interface in order for R3's routes to be sent to R6 and R6's routes to be sent to R3. 

3. One more thing. When R5 sends routes form R3 to R6 and vice versa it will use its interface IP of 

192.168.3.5 as the next hop

for the respective routes. You can disable this with the

no ip next-hop-self eigrp <autonomous-system-number> interface

command on

R5's F0/0

interface. So when R3 sends its routing updates to R5 and R5 turns around and send those same updates on the same interface to R6 it will preserve R3s IP address. So when R6 receives the routes form R5 it will see them with a next hop of R3's interface address and can send traffic directly to R3 while learning about R3s routes indirectly from R5.

Hope that helps

-David

[hfakoor222]

Wow, Thank You

[hfakoor222]

For number 2 I used a gateway prefix list on the interface to achieve my task.

Here on R3's routing table before the prefix-list:

I create this prefix-list

and apply it via a distribute list on the f0/0 interface (in my case it is e0/0):

The routing table is filtering out all next hops of 192.168.3.6:

My iou image was not supporting extended distribute in on an interface and so I searched around and found the above solution.

[hfakoor222]

I also turned off split-horizon and applied no ip next-hop-self eigrp on the interface of R5 pointing to R3 and R6, however have not noticed any changes to either R6's or R3's topology table regarding any routes pointing to eachother.

[David Ruess]

Change your prefix list statement to le 32

With the statement above you're only allowing an IP with a /32 mask effectively blocking R5 from sending routes as well.

If you change it to 0.0.0.0/0 le 32 it covers all other IP addresses. Everything else mentioned should work. Keep the split horison and next ho self off as described above. I was able to get this labbed up and it works.

R3(config-router)#do sh ip pref
ip prefix-list test: 2 entries
seq 5 deny 192.168.3.6/32
seq 10 permit 0.0.0.0/0 le 32
R3(config-router)#

-David

[hfakoor222]

after turning off split horizon on R5,  R3 is learning the .16 segment(which is attached fto R6)  from   R6  to R5  and so it seems to be working.

Thanks so much for the effort in helping me.