Task 2.2 redistribution

The solution talks about changing the AD to for already existing OSPF routes in conjunction with changing the AD of EIGRP to 90 and 109 for external routes on R3 and R4.  I do not see why it is necessary to this.

 I think you can meet the goal of this task by only redistributing and tagging.

Correct ?

Comments

  • There may be several ways to accomplish a particular task - it is good to be familiar with all possible solutions, because the most logical/easiest solution may be forbidden in the wording of the task.

    The solution talks about changing the AD to for already existing OSPF routes in conjunction with changing the AD of EIGRP to 90 and 109 for external routes on R3 and R4.  I do not see why it is necessary to this.

     I think you can meet the goal of this task by only redistributing and tagging.

    Correct ?


  • With redistribution problems, there is typically ALWAYS two solutions - AD manipulation; or tagging and filtering. 

    On Dec 24, 2009, at 7:51 AM, cciace_1978 wrote:

    The solution talks about changing the AD to for already existing OSPF routes in conjunction with changing the AD of EIGRP to 90 and 109 for external routes on R3 and R4.  I do not see why it is necessary to this.

     I think you can meet the goal of this task by only redistributing and tagging.

    Correct ?




    Internetwork Expert - The Industry Leader in CCIE Preparation
    http://www.internetworkexpert.com

    Subscription information may be found at:
    http://www.ieoc.com/forums/ForumSubscriptions.aspx

  • The only problem is the external routes of EIGRP that they are coming from eigrp 10 and the ospf networks downstream of R1. A solution that worked for me was to apply the following to R1,R3,R4:

    access-list 50 permit 200.0.0.0
    access-list 50 permit 200.0.1.0
    access-list 50 permit 200.0.2.0
    access-list 50 permit 200.0.3.0
    access-list 50 permit 54.1.1.0
    access-list 50 permit 204.12.1.0
    access-list 50 permit 130.1.8.0
    access-list 50 permit 130.1.78.0
    access-list 50 permit 150.1.8.8
    access-list 50 permit 150.1.7.7
    access-list 50 permit 130.1.17.0

    !

    router ospf 1
     distance 171 0.0.0.0 255.255.255.255 50

     

     

  • Hi all,

       The May updates will contain a detailed breakdown on this task.

    Regards,

  • Hi Chrisitan,

    I just had a look at the latest updates (August), but there is still no detailed breakdown for this task.

    As far as I can tell, the only issue with redistribution in this lab is the fact that EIGRP has some EX routes in the table (coming from R6 and R1). Redistributing EIGRP in OSPF will cause some issues, but these can be resolved by lowering the distance for external OSPF routes. I do not see why this task is using tagging and filtering.

    Could you please post the detailed breakdown for this task?

    Thanks in advance.

     

  • I was doing distance based on an ACL, too. The only routes that concerned me were native External EIGRP routes from R1 and R6 based on High-to-Low-Back-to-High reasoning.

    Right now redistribution to me is voodoo. Is there a paint-by-numbers guide to redisitribution anwhere? I can do it, but if you present me with the same scenario in a week, I'll come up with a different solution.

  • I just applied:

     distance ospf external 171

    on both R3 and R4, this should be the simplest way to fix suboptimal routing.

    Agree?

  • I just applied:

     distance ospf external 171

    on both R3 and R4, this should be the simplest way to fix suboptimal routing.

    Agree?

    It is enough only up to the moment you redistribute sth directly into ospf. But in this particular scenario I would say that it definitely fix all issues.

    I just did tag filtering without raising ospf external distance. It will ensure routing tables stability, but can cause suboptimal routing. Anyway, one of my favourite quote about CCIE RS LAB exam is "lab is looking for reachability, not for optimal reachability" so I just hope that it's okay.

     

  • Hello All,
    First I would say there are several ways to resolve issues related to complex route redistribution. Care should be taken with regard lab requirement.

    Here is my logic on this: For me to run into issues (looping and suboptimal routes) with redistribution, the routes from one of the routers performing the redistribution have to make it to other RIB; therefore I just prevent the routes related to redistribution to make it to each other routing table.
    I tested it, but somewhat I don’t feel like I should try it in the lab (the reason is, if one of my link fails, I might not be able to use another path that might be available).

    Any thoughts from others?

    Brian, Critian, Anthony (…) could you, please chime in?

    =====================
    R3

    route-map RMAP_SET-TAG permit 10
    set tag 34

    route-map RMAP_FROM-R4 deny 10
    match tag 43
    route-map RMAP_FROM-R4 permit 20

    router eigrp 100
    distribute-list route-map RMAP_FROM-R4 in
    redistribure ospf 1 metric 100000 10000 255 1 1500 route-map RMAP_SET-TAG


    router ospf 1
    distribute-list route-map RMAP_FROM-R3 in
    redistribute eigrp 100 subnets route-map RMAP_SET-TAG

    R4

    route-map RMAP_SET-TAG permit 10
    set tag 43

    route-map RMAP_FROM-R3 deny 10
    match tag 34
    route-map RMAP_FROM-R3 permit 20

    router eigrp 100
    distribute-list route-map RMAP_FROM-R3 in
    redistribure ospf 1 metric 100000 10000 255 1 1500 route-map RMAP_SET-TAG


    router ospf 1
    distribute-list route-map RMAP_FROM-R3 in
    redistribute eigrp 100 subnets route-map RMAP_SET-TAG
    =====================

    Thanks in advance

  • I did the same thing, raised external ospf distance on R3 and R4 to 171 and had full, stable reachability.  I didn't see a need for tag based filtering for this topology.

     

    Edit: I take it back.  I see the tag based filtering is needed for the VRRP track task later on.

     

    I just applied:

     distance ospf external 171

    on both R3 and R4, this should be the simplest way to fix suboptimal routing.

    Agree?

    It is enough only up to the moment you redistribute sth directly into ospf. But in this particular scenario I would say that it definitely fix all issues.

    I just did tag filtering without raising ospf external distance. It will ensure routing tables stability, but can cause suboptimal routing. Anyway, one of my favourite quote about CCIE RS LAB exam is "lab is looking for reachability, not for optimal reachability" so I just hope that it's okay.

     

     

  • I'm not quite sure why I need to tag filter the OSPF redistribution on R3 and R4. The routes coming from OSPF on R1 will go into EIGRP with AD 170, and there's no other redistribution point for those routes, if R2 or R4 send them back via EIGRP, then the OSPF routes won't be superseded by the EIGRP ones due to OSPF's lower AD, so there's no problem with the redistribution on R1.

    On R6, there's only one path into the routing domain. Normally, split horizon and the feasability check should prevent the routes from coming back to R6 via EIGRP, however the redistribution on R3 and R4 does allow another source for these routes into the domain, which is wrong. So what I did was tag EIGRP 10 into EIGRP 100, and prevented those tagged routes from going back into EIGRP on R3 and R4. The SG's solution would also prevent that, but it's overkill, as tagging OSPF into EIGRP is entirely unncessary.

    R3 and R4, there's a potential problem. If R3 sends the eigrp 170 routes into OSPF, they'll become AD 110 by the time they reach R4 (and vice versa), so suboptimal routing occurs. The OSPF routes that R3 sends into EIGRP will become AD 170, so that when they reach R4, it won't supplant native OSPF routes with routes redistributed into EIGRP. 

    So the only issue I see is the possibility or R3 or R4 preferring redistributed EIGRP routes into OSPF due to OSPF's lower AD, and raising external OSPF AD to 171 solves that problem, while still allowing R5 to keep full connectivity. 

     

    Tagging OSPF into EIGRP makes no sense here. Since redistribution happens from the routing table, and external EIGRP is higher than native OSPF, anything that had the OSPF routes via OSPF will have them in the routing table already via OSPF. In order to actually go into OSPF from EIGRP, they'd have to be in the routing table already via EIGRP, and the only way that happens is if the link to the OSPF domain is down, at which point you would want the routes via EIGRP if you want to maintain full connectivity. 

    Likewise, tagging EIGRP into OSPF makes no sense *if* you're raising the OSPF AD at the same time on the redistributing routers. Since EIGRP to OSPF external would put the AD at 171, the external EIGRP's would be preferred in the routing table, so the external EIGRP routes would never come back in via redistribution from OSPF.

    So near as I can tell, the simplest way to complete this task is to do the redistribution as required, and raise external OSPF on R4 and R3 to 171, and that's it, done. 

    If there's something I'm missing, I beg you to explain. If I'm misunderstanding redistribution at this point of the game, that's a serious problem.

  • Edit: I take it back.  I see the tag based filtering is needed for the VRRP track task later on.

     

     

    Edit: Nevermind, as I outlined above, not using tag filtering for EIGRP 10 into EIGRP 100 is bad juju, and will result in a problem with R6 learning BB1's routes from another source.

  • Here is what I did:

    R3 and R4:

    router eigrp 100

    eigrp router-id 34.34.34.34

    (so that their router-ids are the same)

    distance eigrp 90 109

    (so that the external distance of EIGRP is lower than OSPF, we give the "power" to EIGRP on both R3 and R4)

     

    Mutually redistribute between both protocols on both routers

    voala!

    This way, all external EX routes on both R3,R4 will be preferred through EIGRP and not thourgh OSPF at 110 when EIGRP to OSPF redist happens  (since they are at 109). When a OSPF route on R4 at 110 (that R3 also knows via OSPF at 110) gets redist into EIGRP by R4, R3 will ignore it since it came from a router with the same router id. This prevents R3, and R4 likewise when R3 puts a route into EIGRP from OSPF, from learning routes via a lower AD (109) and just keep their native 110 OSPF routes when OSPF->EIGRP redist occurs. 

    This solution seems much simpler to me, it works, and does not violate any restrictions.

    What do you think?

  • So there is no need to connect both OSPF domains using VL/Tunnel?

    Can somebody shed some light, why not in this case and/or When we should?

    Thanks!

  •  

    r1, r3, r4

    !

    router ospf 1

    distance ospf external 171

     

    4 points.

     

    :)

     

    EDIT:

     

    Here's my work:

     

     

     

    image

     

    Redistribution diagram is at the bottom.

     

    It shows that the two ospf domains are edge domains of eigrp AS 100.  So I simply told the border routers that ospf external routes are always less believable than eigrp external routes.

     

    This is where learning how to sketch up redistribution diagrams is paying off off.  My thinking is route tags work is most cases, but it's more code to write and debug.  Admin distance is always quicker as long as it's feasible and meets the requirements.

Sign In or Register to comment.