9.21 ipv6 redistribution

I'm confuse about why set the distance of ospf external route to 171. Isn't 121 enough? I know the eigrp external route has the distance of 170, but ospf external route wouldn't affect that part. I think the reason we adjust the distance on R6 is because the redistribution of RIP to OSPF. The external route ospf learn from rip will advertice to R6 with the distance of 110, so the R6 will use the ospf route to reach the prefix that in rip area. But as the eigrp internal route has a distance of 90 which is better than ospf, it won't has the same problem. So why set the distance to 171? Is there any point that I missed?

Comments

  • Even I do not understand why is it done?

    Also had the following doubts:

    (1) Any particular reason the metric is set to 8 for redistributed routes

    (2) Also what is meant by the 2nd question and how are we handling it - Ensure each protocol prefers to reach native prefixes using internal paths.

    Can somebody assist?

  • Even I am not able to get this question clear.

  • Hi,

    Using a distance of 121 or 171 achieves the same thing. We are just trying to stop external ospf routes (default distance 110) from preempting RIP (distance 120).

    Crownade

  • (2) Also what is meant by the 2nd question and how are we handling it -
    Ensure each protocol prefers to reach native prefixes using internal
    paths.

     

    Meaning that the redistribute route do not take over the original (native route)

     

    AD

    RIP : All 120

    OSPF: All 110

    EIGRP: Int = 90, Ext 170

    BGP: Int 20, Ext 140

     

    When we redistribute RIP into OSPF, the route AD change to 110 then I will overwrite the original RIP route that have AD 120. So to prevent it we change the AD of the external OSPF route to 171.

  • I am still puzzle why we have to configure the external ospf distance on R6? Why not R4, R1, R3?? Any one can enlighten me. Thank you

  • The point of increasing the distance of ospf external routes on R6 is so that R6 will prefer the native RIP routes with AD120 over the redistributed from RIP to OSPF routes from R5 that would be AD110 by default. 

    For example a loopback advertised into RIP on R1 would be seen as an ospf E2 route with the default ospf AD of 110 because it was redistributed to ospf in R5.  Increasing the AD of ospf external routes on R6 to any distance above 120 would suffice to fix this.

     

    There is no need to manipulate distance on R1 and R3 because these routers only have one routing process (R1 is only RIP and R3 is only OSPF)

    There is no need to manipulate distance on R4 because EIGRP already does that with internal AD of 90 and external AD of 170.

     

    HTH

  • I c ....Thank you Desmond...

    R6 running rip and ospf . It redistribute back the original RIP route to OSPF as external ospf route with AD 110 and overwrite the original RIP route (with metric 120), so we change it to any metric above 120.

    Rack1R6#sh ipv route FC00:1:0:1::1
    IPv6 Routing Table - 26 entries
    Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
           U - Per-user Static route, M - MIPv6
           I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
           O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
           ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
           D - EIGRP, EX - EIGRP external
    R   FC00:1:0:1::/64 [120/4]
         via FE80::C000:EFF:FE20:1, FastEthernet0/0.146

    while R1, R3, and R4 has no such things

    R3 also running ospf and edistribute back the original RIP route to OSPF as external ospf route with AD 110, but no RIP here so it safe.

    Rack1R3#sh ipv route FC00:1:0:1::1
    IPv6 Routing Table - 17 entries
    Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
           U - Per-user Static route, M - MIPv6
           I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
           O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
           ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
           D - EIGRP, EX - EIGRP external
    OE2  FC00:1:0:1::/64 [110/8]
         via FE80::5, Serial1/0

    The point of increasing the distance of ospf external routes on R6 is so that R6 will prefer the native RIP routes with AD120 over the redistributed from RIP to OSPF routes from R5 that would be AD110 by default. 

    For example a loopback advertised into RIP on R1 would be seen as an ospf E2 route with the default ospf AD of 110 because it was redistributed to ospf in R5.  Increasing the AD of ospf external routes on R6 to any distance above 120 would suffice to fix this.

     

    There is no need to manipulate distance on R1 and R3 because these routers only have one routing process (R1 is only RIP and R3 is only OSPF)

    There is no need to manipulate distance on R4 because EIGRP already does that with internal AD of 90 and external AD of 170.

     

    HTH

     

  • I don't see any real reason on putting a metric when redistributing to OSPF because in this scenario there is only one point of redistribution.

    For RIP however, metric is required although same applies here,  there is only one point of redistribution.  But remember it is always good practice to make redistributed routes have a higher metric than your highest native routes.

    Check out INE's ATCOD on redistribution by Keith if you haven't already.  He did a good job on this topic although it was on IPv4 same rules apply.

  • This task is very messy. If we try to draw this in a diagram it's not very easy. R4 and R5 are running both RIPNG and EIGRPv6 over their serial links and R5 is running both OSPFv3 and EIGRPv6 over fa0/0 to SW2.

    This makes it difficult knowing which prefixes are native. I guess we must assume that if two protocols are running over the same interface then the protocol with the lowest AD is the one that is native since this is the one that will be installed in the routing table? If we are running OSPF then it could still be in LSDB though.

    Could we expect something as messy as this at the lab? I don't really see the point of this lab since there are too many components involved but maybe that is the point? :)

  • Hi Daniel,

       Chances are almost close to Null0 to get such thing in the lab. Still, these kind of labs makes your brain function and to be honest this is what i love at INE labs. If you make/configure only regular/usual scenarios, your brain just makes some patterns and you do not really get how technology works (it may not aply to you at this moment, cause most probably you got over that point). However, for the lab, although tasks may look simple, take care and try to really understand what is asked of you. Take EIGRP for example, you have very few commands for it, however it is a very complex protocol, which is not usually undestood 100% by all engineers and through its apparent simplicity, debugging is a lot more difficult.

    Good luck with your studies!

  • Thanks Cristian,

    Yes, I try not to oversimplify things either. Since we only have one point of redistribution we should not worry about loops. I could easily have forgotten that R6 will install native RIP routes as OSPF routes so that is good practice.

  • Hi, great task :)

    My question comes from igp's into eigrp redistribution :

    here's interfaces that participate in ipv6 eigrp :

    IPv6 Routing Protocol is "eigrp 100"
      EIGRP metric weight K1=0, K2=0, K3=1, K4=0, K5=0      < K-value set for DELAY only
      EIGRP maximum hopcount 100
      EIGRP maximum metric variance 3
      Interfaces:
        FastEthernet0/0
        Serial0/0
        Serial0/1
        Loopback100

     

    However delay values in dynamips vary : 

    my f0/0 interface has :

    MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
         reliability 255/255, txload 1/255, rxload 1/255

     my s0/0 interface is :

     MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec,
         reliability 255/255, txload 1/255, rxload 1/255

    my s0/1 interface has :

      MTU 1500 bytes, BW 1544 Kbit/sec, DLY 10000 usec,
         reliability 255/255, txload 1/255, rxload 1/255

    and my lo100 interface is :

      MTU 1514 bytes, BW 8000000 Kbit/sec, DLY 5000 usec,
         reliability 255/255, txload 1/255, rxload 1/255

     

    in solution redistributing happens as :

    reidstribute [rip/ospf] include-connected metric 1000        0          255          1         1500

                                                                                      bw        delay    reliabilty     load      mtu

     

    Why are we skipping delay ?

    Thanks !

     

     

     

     

     

     

     

     

     

Sign In or Register to comment.