We have completed the upgrade of IEOC! All posts, comments and user profiles have been migrated. For security reasons, we have reset all passwords. To set a new password please Click Here. Further updates soon to follow.

Redistribution Case 2 (The infinite updates)

Hi,

 

I am running a similar case to "Redistribution Case 2" in the INE v5 Workbook 

in this topology,

 

image

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

The link between R1 and R3 run both OSPF and EIGRP, and they are adjacent with each other through both protocols.

Both R7 and R3 redistribute external prefixes with equal metric.

now, R7 redistribute its connected interface loopback0 10.0.7.7/32 into EIGRP, R2 receives this and advertise to R1 and R4,

R1 will redistribute it to OSPF and send it to R3 and R5, it will also send EIGRP update to R3

R3 will receive two updates to 10.0.7.7/32, one is EIGRP external with AD of 170 from both R1 and R4, and other OSPF external with AD of 110 from R1

R3 will prefer OSPF path and then redisitrbitue OSPF into EIGRP, and send update to R1 and R4,

when R1 receives this update, it will think R3 is closer to R7 loopback than R2, so it will install it and remove R2 route. Then it will again redistribute this update into OSPF and sends it to R3. R3 will redistribute it again into EIGRP. This update happens indefinitely

 

What I have noticed is that R1 flaps on 10.0.7.7/32 between R2 and R3, sometimes it install through R2, and after few seconds install it through R3,

R3 sometimes install 10.0.7.7/32 through OSPF through R1, and sometimes through External EIGRP through R1 and R4

 

regardless of the solution to this problem, and regardless of the infinite update between R1 and R3,

why would R1 and R3 flaps thier routes to R7, if they are only sending updates to each other, and this update carry same information?

 

thanks,

 

 

Comments

  • JoeMJoeM ✭✭

    regardless of the solution to this problem, and regardless of the infinite update between R1 and R3,


    why would R1 and R3 flaps thier routes to R7, if they are only sending updates to each other, and this update carry same information?

    Well there is a reason.  R3 should not be redistributing EIGRP routes back into EIGRP.   That is a mistake, right?

    It is good to know this scenario solid with mutual redistribution.   There are a few ways to solve this. 

     

    You explained the redistribution process very well.  R1 thinks it learned a closer route (repeat).

            R1: I'm the guy redistributing from R7 (not confused)


            ....wait....no....R3 has a better route metric (update and redistribute)


            ....wait....no....now R7 has a better route metric (update and redistribute)


            ....wait....no....again R3 has a better route metric (update and redistribute)


               etc etc etc

     

    Since I believe that the flapping is due to a metric change, we need a capture of some sort to prove this.

    Maybe try debug ip routing so that we can see the metrics for each update as they happen.

     

    If you do this, just give us the update info. 

    It should look like this, but for EIGRP.

    RT: add 5.5.5.5/32 via 56.56.56.5, isis metric [115/20]

     

    Hope this helps!   Please post your findings.

  • JoeMJoeM ✭✭

    Hello Oudmaster,
    Have you had a chance to look at this? I am curious as to what you find in your lab.

  • Hi JoeM,

    I apologize, I am on short leave and away from my lab, I will reply to you soon once I get back.
    thanks for following up with me.

  • oudmasteroudmaster
    edited May 19

    Hi JoeM,

    here are some information I got,

    Since R1 get better EIGRP metric through R3, then it should never consider the path through R2 (because 10.0.7.7/32 through R2 has higher metric)

    the debug ip routing detail does not give me a good view of what is going on:

    here is on R1:
    R1#**debug ip routing detail **
    IP routing debugging is on (detailed)

    *May 19 15:19:02.155: Periodic IP routing statistics collection

    *May 19 15:19:05.567: RT: updating eigrp 10.0.7.7/32 (0x0) :
    via 10.0.12.2 Gi1/0

    *May 19 15:19:05.571: RT: updating eigrp 10.0.7.7/32 (0x0) :
    via 10.0.13.3 Gi2/0

    *May 19 15:19:05.571: RT: del 10.0.7.7/32 via 10.0.12.2, eigrp metric [170/3328]
    *May 19 15:19:05.571: RT: add 10.0.7.7/32 via 10.0.13.3, eigrp metric [170/3072]

    *May 19 15:19:07.155: Periodic IP routing statistics collection

    *May 19 15:19:10.527: RT: delete route to 10.0.7.7 via 10.0.13.3, eigrp metric [170/3072]
    *May 19 15:19:10.527: RT: no routes to 10.0.7.7, delayed flush
    *May 19 15:19:10.531: RT: delete subnet route to 10.0.7.7/32
    *May 19 15:19:10.535: RT: updating eigrp 10.0.7.7/32 (0x0) :
    via 10.0.13.3 Gi2/0

    *May 19 15:19:10.535: RT: rib update return code: 5
    *May 19 15:19:10.539: RT: updating eigrp 10.0.7.7/32 (0x0) :
    via 10.0.12.2 Gi1/0

    *May 19 15:19:10.543: RT: add 10.0.7.7/32 via 10.0.12.2, eigrp metric [170/3328]

    *May 19 15:19:12.155: Periodic IP routing statistics collection

    *May 19 15:19:15.559: RT: updating eigrp 10.0.7.7/32 (0x0) :
    via 10.0.12.2 Gi1/0

    *May 19 15:19:15.559: RT: updating eigrp 10.0.7.7/32 (0x0) :
    via 10.0.13.3 Gi2/0

    *May 19 15:19:15.559: RT: del 10.0.7.7/32 via 10.0.12.2, eigrp metric [170/3328]
    *May 19 15:19:15.559: RT: add 10.0.7.7/32 via 10.0.13.3, eigrp metric [170/3072]

    and here is on R3:
    R3#**debug ip routing detail **
    *May 19 15:25:00.571: RT: del 10.0.7.7 via 10.0.13.1, ospf metric [110/20]
    *May 19 15:25:00.575: RT: delete subnet route to 10.0.7.7/32
    *May 19 15:25:00.695: RT: updating eigrp 10.0.7.7/32 (0x0) :
    via 10.0.13.1 Gi2/0

    *May 19 15:25:00.695: RT: add 10.0.7.7/32 via 10.0.13.1, eigrp metric [170/3584]
    *May 19 15:25:00.695: RT: updating eigrp 10.0.7.7/32 (0x0) :
    via 10.0.34.4 Gi1/0

    *May 19 15:25:00.695: RT: add 10.0.7.7/32 via 10.0.34.4, eigrp metric [170/3584]

    *May 19 15:25:01.963: Periodic IP routing statistics collection

    *May 19 15:25:05.591: RT: updating ospf 10.0.7.7/32 (0x0) :
    via 10.0.13.1 Gi2/0

    *May 19 15:25:05.595: RT: closer admin distance for 10.0.7.7, flushing 2 routes
    *May 19 15:25:05.595: RT: add 10.0.7.7/32 via 10.0.13.1, ospf metric [110/20]
    *May 19 15:25:05.655: RT: updating eigrp 10.0.7.7/32 (0x0) :
    via 10.0.13.1 Gi2/0

    *May 19 15:25:05.655: RT: rib update return code: 17
    *May 19 15:25:05.655: RT: updating eigrp 10.0.7.7/32 (0x0) :
    via 10.0.34.4 Gi1/0

    *May 19 15:25:05.659: RT: rib update return code: 17
    *May 19 15:25:05.751: RT: updating eigrp 10.0.7.7/32 (0x0) :
    via 10.0.34.4 Gi1/0

    *May 19 15:25:05.755: RT: rib update return code: 17
    *May 19 15:25:06.963: Periodic IP routing statistics collection

    *May 19 15:25:10.591: RT: del 10.0.7.7 via 10.0.13.1, ospf metric [110/20]
    *May 19 15:25:10.595: RT: delete subnet route to 10.0.7.7/32
    *May 19 15:25:10.759: RT: updating eigrp 10.0.7.7/32 (0x0) :
    via 10.0.13.1 Gi2/0

    From these two debugs, I got two questions which they dont show me,

    Q1\ why R1 remove the EIGRP external update after few seconds from receiving it from R3, and then install R2?

    Q2\ why R3 delete OSPF route after receiving it received from R1 within few seconds ?

    BTW, here is the updates flaps between R1 and R3 as it appears in WireShark

  • JoeMJoeM ✭✭
    edited May 19

    I replied to this, but my post disappeared. Not sure why.

    **Question: ** Are you using EIGRP and OSPF over the link between R1 and R3? Not a good situation, and probably not productive for redistribution practice.

    ! First part of your debug shows that the metric forcing the change

    RT: updating eigrp 10.0.7.7/32 (0x0) :
    via 10.0.12.2 Gi1/0

    RT: updating eigrp 10.0.7.7/32 (0x0) :
    via 10.0.13.3 Gi2/0

    RT: del 10.0.7.7/32 via 10.0.12.2, eigrp metric [170/3328]
    RT: add 10.0.7.7/32 via 10.0.13.3, eigrp metric [170/3072]

  • oudmasteroudmaster
    edited May 20

    yes R1 and R3 running OSPF and EIGRP and they are adjacent with each other on the same link. I do agree with you that this is not a good design, however the Lab in INE WB is configured to something similar to this and wants us to provide solution.

    my query is regardless of the solution to provide (I already founded list of solutions to this problem),
    is why R1 and R3 flaps about this route 10.0.7.7/32?, I was expecting R1 to always prefer R3 because R2 advertise it with higher metric, at the same time R3 should prefer R1 always through OSPF (lower AD), if there is continues updates, it is fine, but why they keep removing it from their routing table, this is I dont get it.

    I tried to insert all of the following debugs one shot, but could not understand the output :)

    debug ip routing det
    debug eigrp fs
    debug ip ospf spf
    debug eigrp packets update
    debug ip ospf pack

    if you are interested to see the debug, I can upload it, because they are a lot.

Sign In or Register to comment.