Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

EIGRP startup/Poison reverse confusion

Hi all.

Referring to the following doc

http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a0080094cb7.shtml#splithorizon

Startup Mode

When two routers first become neighbors, they exchange topology tables       during startup mode. For each table entry a router receives during startup       mode, it advertises the same entry back to its new neighbor with a maximum       metric (poison route).

Now i have 2 routers

R1 (E0/0)---------------------Switch------------------------(E0/0) R2

I have a loopback configured on R1 i.e. 1.1.1.1/24. I advertised it under eigrp 100 no autosummary). Now i enabled eigrp on R2. While capturing packets through wireshark, according to the above statement, i should be able to see an poison update regarding 1.1.1.0/24 from R3 -> R1 isnt it ? but i am not able to see any update going from R3 to R1 that contains 1.1.1.0/24 as unreachable !!

Why is this so ?

1 ACCEPTED SOLUTION

Accepted Solutions
Hall of Fame Super Silver

Re: EIGRP startup/Poison reverse confusion

Hello Jonn,

generally speaking poison reverse overrides split horizon:

an explicit update with infinite metric is sent instead of skipping the update for a prefix learned on that interface.

So poison reverse provides benefits in redundant topologies avoiding the count to infinity that could be triggered in some conditions.

However, all this is important for RIP or IGRP:  EIGRP has the DUAL algorithm to deal with topology changes and this specific aspect you are testing applies to a starting router (starting to talk EIGRP on segment)

Again, I'm not sure you can see this but I agree with Hitesh that appropriate debug commands on the routers can be of help instead of decoding EIGRP packets captured by wireshark.

Hope to help

Giuseppe

4 REPLIES

Re: EIGRP startup/Poison reverse confusion

try debugging on R1 and R2 using "debug eigrp fsm". you will see the results.

HTH

Hitesh Vinzoda

Please rate useful posts

Hall of Fame Super Silver

Re: EIGRP startup/Poison reverse confusion

Hello Jonn,

I've never tried to see this.

However, I would suggest to add a router R0 before R1 and to focus on routes originated on R0 that R1 passes to R2 when R2 starts talking EIGRP on common segment.

Because EIGRP internal route data structure contains that famous hop count field we had discussed in another thread, R2 can know that the IP subnet is directly connected to R1 and it can suppress this poison reverse update.

In receiving updates originated by R0 the hop count will be greater then 0 and R2 might send this poison reverse.

I think that what is really important to know about EIGRP startup is that split horizon is not honored during startup so a router will answer to initial request of starting device will all known routes including those learned on the segment (split horizon exception)

Hope to help

Giuseppe

New Member

Re: EIGRP startup/Poison reverse confusion

Dear Sir,

When i was thinking about it, i think i am confused about 1 point.

1) Do split horizon stops posion reverse updates as well ? mean if an update is poisoned and send back out the same interface, is it possible that split horizon stops this packet ?

Hall of Fame Super Silver

Re: EIGRP startup/Poison reverse confusion

Hello Jonn,

generally speaking poison reverse overrides split horizon:

an explicit update with infinite metric is sent instead of skipping the update for a prefix learned on that interface.

So poison reverse provides benefits in redundant topologies avoiding the count to infinity that could be triggered in some conditions.

However, all this is important for RIP or IGRP:  EIGRP has the DUAL algorithm to deal with topology changes and this specific aspect you are testing applies to a starting router (starting to talk EIGRP on segment)

Again, I'm not sure you can see this but I agree with Hitesh that appropriate debug commands on the routers can be of help instead of decoding EIGRP packets captured by wireshark.

Hope to help

Giuseppe

1996
Views
0
Helpful
4
Replies