4.11

From the lack of posts here, I get the feeling most people just gave up on this one. The solution in the workbook only works when the network is in the intial state; but try it with the backup link up (between R4 and R5) and you still get the R2-R3 loop problem.

I also went through all the 'solutions' in the blog. The only solution for R2 and R3 that works for both states is the summary address solution. Specifically...

On R2 and R3 -- not needed on R4 BTW
  router ospf 1
   summary-address 132.1.4.0 255.255.254.0
   summary-address 192.10.0.0 255.255.254.0

It seems like a simple solution when you look at the config -- but to get to this point takes finesse; using a summary route here is the definition of elegance. Which is why this ain't no difficulty 6 redistribution problem! I suppose the objective is to recognize that this is a grusome problem and is just too time consuming to figure out. Best to forgo the 5 points (4.7 + 4.11) and move on, as Brian Dennis' blog implies. The trick is being able to see the problem -- a two state routing loop. And, mind you, not just two states -- but the first state has R5 externals learned via EIGRP and the second state (backup) has R5 externals learned via OSPF. That's rough!!

[I] I think at this level (6), network 132.1.23.0/24 should be OSPF. Then the goal of this task is that your site routing protocols (EIGRP, in this case) should be more trustworthy (lower AD) than your WAN routing protocols (OSPF). So the solution is simply to raise OSPF's AD above EIGRP's AD -- which means you have to pay attention to the fact that EIGRP externals have a high AD (170). It seems that is what the solution breakdown should describe -- if there was one.... [:^)]

 

 

Comments

  • so in nutshell the problem is

    the solution in the solution guide is only fixing loop when the primary link is up

    but when the backup is up

     we will have loop between R2 and R3 for R5 networks

     

     

    I suggest to add some command in R2 and R3 which will fix this issue and will not cause any problem when the primary link is up

     

     

    Simply if we add those commands in R2 and R3

    Distance 113 4.4.4.4 0.0.0.0 ospf2

     

    ip access-list standard ospf2

     permit 192.10.1.0 0.0.0.255

     permit 132.1.45.0 0.0.0.255

     permit 132.1.5.0 0.0.0.255

     permit 150.1.5.0 0.0.0.255

     

    I have try it by my self and I think it's working

  • I have try it by my self and I think it's working

     

    Right. So when you finish task 6.3 try....

    R6#p 228.28.28.28 re 5 so 132.1.6.6

     

    Let me know if that works. Thanks.

  • hi

    i m  not touching the other command

    i m adding command not removing any command

    which always make R3 select R6 multicast network using the FR link

    as you can see in the solution guide the ACL in the

    Distance 110 .............................................ACL

    in R3 also matching R6 multicast netwrok so it's ok

    i have send mail to brain magahan 

    '[email protected]'

    from internetwrok expert to take alook of this and give us his voice

    and fix or add more explanition in the solution guide

     i hope he answer me , and  if you have any link to someone in INTERNETWORK EXPERT how can solve this issue

     

    thanks

    ayman.aborabh

    alex,egypt

  • Actually there is one solution.

    1. Mutually redistribute EIGRP 10 and OSPF on R2, R3 and R4.

    2. Remove 'network 132.1.23.0 0.0.0.255' from EIGRP 10 on R2 and R3.

    3. On R2 and R3, redistribute 132.1.23.0 into EIGRP, making the AD for this link 170.

    router eigrp 10
     redistribute connected metric 1 1 1 1 1 route-map CON-EX

    route-map CON-EX permit 10
     match interface Serialx/x
    route-map CON-EX permit 999

    This is a very cool solution because if you look at the network, the core should be OSPF. But that pesky EIGRP link between R2 and R3 messes things up because EIGRP has an AD of 90 which is prefered over OSPF (110). Unfortuntely, this solution might violate task 4.4 -- it depends how you interpret the requirement to "enable EIGRP...". I did enable EIGRP, right?

     

    BTW -- is there a way to set the AD higher for a connected interface without redistributing?

  • you are saying this

    "there is one solution"

    i think there is other solution if u check the old forum u will see the people are thaking about solution using taging and route-map

    i didnt try it , it may work ,

    that's way i send the mail to B.machan to clear this thing

    and for ur point of view about enable eigrp i think u loss of this quitsion  the point because u didnt enable ( i think that )

    but  if u do that how that going to solve the loop for network

    192.10.1.0 , 132.1.5.0 , 150.1.5.0

    between R2 and R3 ?

     

  • i dont know other way to change the AD of conect only redistribution

  • You are right -- there may be other solutions -- but this one...

    A. fixes the routing loop between R2 and R3

    B. works when the backup link between R4 and R5 is up

    C. works with multicast (R6#p 228.28.28.28 re 5 so 132.1.6.6)

    D. is easy to implement

    and is very logical because it forces OSPF to be the core routing protocol between EIGRP local sites.

  • but  if u do that how that going to solve the loop for network

     

    To answer your question....

    Think of R2 and R6 as "Site 2". R3 and R5 are "Site 3".

    Site 2 and Site 3 are connected via two connections. One is OSPF over Frame Relay, and the other connection is EIGRP over HDLC. Imagine that the EIGRP over HDLC connection wasn't there.... Everything would be fine; these sites would have a more prefered routing protocol locally (EIGRP, AD 90). OSPF would be the WAN routing protocol with a less trusted AD of 110. Ideally that redundant link between R2 and R3 should be OSPF -- that would be a better design. But this is the CCIE  lab exam, so we need to find a way to make that link less prefered than OSPF. That's why we need to redistribute connected to get the AD higher than 110. Once that's done, Site 2 and Site 3 communicate via OSPF (unless the frame relay link goes down).

  • now i beleive in what u said before that we are wasting our time

    we get the idea and the concept but now we are playing and try to find more and more solution

    and

     i give up and move toward lab 3

    what about u ?

    we have alot of labs to do and a lot of tricks to know

    i had sechudeled me exam at december ? u? 

  • I never give up...usually. Seriously though I think any redistribution problem is worth spending alot of time on -- especially when the workbook solution isn't right. This particular network bothers me because it looks so simple. It's an excellent lesson in ADs.

    I'm scheduled for December but I have no problem moving it back if I need more time. And I've got so much to relearn. [H]

  • redistribution is the hardest topic in CCIE. not that it is hard to understand, but because it needs LOTS of time to look at.

     

    personally, I will cowardly not do mutual redistribution in my lab.. I'm all happy to lose 3 points :D

     

    I'll merely allow full reachability, and happily rest of points.

     

    just in case it happened to have plenty of time, then i'll fancy my lab by looking at it.. else NOOOO WAAAY!

  • I just want to document this solution while it's still fresh.

    The concept is simple; view the network design as a single FR WAN running OPSF connecting four sites. The sites we are interested in are running EIGRP locally. This makes sense since EIGRP has an AD of 90 and OSPF has an AD of 110; EIGRP is prefered locally.

    The problem in the design is that there is a redundant WAN connection between R2 and R3 (132.1.23.0/24). If this connection were OSPF, there would be no issue. But it's EIGRP, and is prefered over the OSPF. This causes a routing loop between R2 and R3 when we mutually redistribute EIGRP and OSPF.
     
    Ideally, we would like to increase the AD for 132.1.23.0/24 to something over 110 so that the OSPF link is prefered. To do that, we redistribute the physical interfaces of 132.1.23.0/24 into EIGRP. This increases the AD for 132.1.23.0/24 to 170. Now the OSPF network (132.1.0.0/24) is prefered between R2 and R3. As a consequence, 132.1.23.0/24 is not used unless the FR network goes down.

    Additionally, we need to redistribute the connected 132.1.23.0/24 network into OSPF. This is an interesting point that was touched upon in Lab 1, task 3.11. The key point is that when mutually redistributing routing protocols on a device, redistributed connected networks do not get further redistributed.
    For example, on R2, we are mutually redistributing OSPF 1 and EIGRP 10. We are also redistributing connected into EIGRP 10. It would seem logical that anything we redistribute into EIGRP would be further redistributed into OSPF. But that's not the case. We have to explicitly redistribute the connected interface into OSPF too. This may seem like a point of contention for the lab but there is nothing specifying how certain networks are learned.

    Note: Some of the LAN interface numbers below are different than the lab document because I'm using Dynagen.

    R2::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
      router eigrp 10
       redistribute connected metric 1 1 1 1 1 route-map CON->EX
       redistribute ospf 1 metric 1 1 1 1 1
       network 132.1.26.0 0.0.0.255
       network 150.1.2.0 0.0.0.255
       no auto-summary
       neighbor 132.1.26.6 FastEthernet1/0
      
      router ospf 1
       log-adjacency-changes
       redistribute connected subnets route-map CON->EX
       redistribute eigrp 10 subnets
       network 132.1.0.0 0.0.0.255 area 0

      route-map CON->EX permit 10
       match interface Serial0/1
      route-map CON->EX permit 999

    R3::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
      router eigrp 10
       redistribute connected metric 1 1 1 1 1 route-map CON->EX
       redistribute ospf 1 metric 1 1 1 1 1
       network 132.1.35.0 0.0.0.255
       network 150.1.3.0 0.0.0.255
       no auto-summary
      
      router ospf 1
       log-adjacency-changes
       redistribute connected subnets route-map CON->EX
       redistribute eigrp 10 subnets
       passive-interface Ethernet0/0
       passive-interface Ethernet0/1
       network 132.1.0.0 0.0.0.255 area 0
       network 132.1.3.0 0.0.0.255 area 3
       network 132.1.33.0 0.0.0.255 area 33

      route-map CON->EX permit 10
       match interface Serial1/3
      route-map CON->EX permit 999

    R4::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
      router eigrp 10
       redistribute ospf 1 metric 1 1 1 1 1
       network 132.1.45.0 0.0.0.255
       no auto-summary
      
      router ospf 1
       log-adjacency-changes
       redistribute eigrp 10 subnets
       network 132.1.0.0 0.0.0.255 area 0
       network 132.1.255.0 0.0.0.255 area 255
       network 150.1.4.0 0.0.0.255 area 0
     
    SW1::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
      router ospf 1
       log-adjacency-changes
       area 17 authentication
       redistribute rip subnets
       network 132.1.17.0 0.0.0.255 area 17

      router rip
       version 2
       redistribute ospf 1 metric 3
       passive-interface default
       no passive-interface Vlan783
       network 150.1.0.0
       network 204.12.1.0
       no auto-summary

  • ive been reading the discussion as well as the solution provided in the workbook. let's forget the fact that the provided solution is wrong.

     

    what does sw1 has to do with allowing 132.1.6.6 to be seen as OSPF for RPF in task 4.11 on R3

     

    the source is 132.1.6.6 and the destination is SW1 which is configured to join group 228.28.28.28

     

    and why is the solution in task 6.3 showing that the traffic is desitned to 132.1.0.3 and not to 132.1.0.1 after all that's where the traffic is sent to so that it reaches sw1

     

  • ive been reading the discussion as well as the solution provided in
    the workbook. let's forget the fact that the provided solution is wrong.

     

    what does sw1 has to do with allowing 132.1.6.6 to be seen as OSPF for RPF in task 4.11 on R3

     

    the source is 132.1.6.6 and the destination is SW1 which is configured to join group 228.28.28.28

     

    and why is the solution in task 6.3 showing that the traffic is
    desitned to 132.1.0.3 and not to 132.1.0.1 after all that's where the
    traffic is sent to so that it reaches sw1

  • hi all,

    well it's too difficult to read all your solutions, anyway i will post mine which seems to be working fine pinging end to end, with and without the R3-R5 link,

    after clearing processes or rebooting.

    it took me some hours to get all routers to reach the connected routes R5 redistributes via eigrp.

    R5 tags both vlan5 and vlan52 connected routes:

    router eigrp 10
     redistribute connected metric 100000 1000 255 1 1500 route-map REDIS_EIGRP_5_52
     network 132.1.35.0 0.0.0.255
     network 132.1.45.0 0.0.0.255
     network 150.1.5.0 0.0.0.255
     no auto-summary
     eigrp router-id 150.1.5.5

    route-map REDIS_EIGRP_5_52 permit 10
     match interface Ethernet0/0 Ethernet0/1
     set tag 555
    !

    R3, nothing special other than the book requested, redistribution ospf-eigrp:

    router eigrp 10
     redistribute ospf 1234 metric 100000 1000 255 1 1500
     network 132.1.23.0 0.0.0.255
     network 132.1.35.0 0.0.0.255
     network 150.1.3.0 0.0.0.255
     no auto-summary
     eigrp router-id 150.1.3.3
    !
    router ospf 1234
     router-id 150.1.3.3
     log-adjacency-changes
     redistribute eigrp 10 subnets
     passive-interface Ethernet0/0
     passive-interface Ethernet0/1

     

    R2 does not inject tagged routes from R5 into the ospf domain,

    router eigrp 10
     redistribute ospf 1234 metric 1 1 1 1 1 (this is useful for avoiding R3 to load balance between R2 and R5 for tag 555 routes)
     network 132.1.23.0 0.0.0.255
     network 132.1.26.0 0.0.0.255
     network 150.1.2.0 0.0.0.255
     no auto-summary
     eigrp router-id 150.1.2.2
     neighbor 132.1.26.6 FastEthernet0/0
    !        
    router ospf 1234
     router-id 150.1.2.2
     log-adjacency-changes
     redistribute eigrp 10 subnets route-map NO_R5_INTO_OSPF

    route-map NO_R5_INTO_OSPF deny 10
     match tag 555
    !
    route-map NO_R5_INTO_OSPF permit 20

    R4, distance 171 makes R4 to announce into OSPF the tag 555 routers learned via R5 with eigrp.

    router ospf 1234
     router-id 150.1.4.4
     log-adjacency-changes
     redistribute eigrp 10 metric 10 subnets
     distance 171 0.0.0.0 255.255.255.255 R5ETH

    router eigrp 10
     redistribute ospf 1234 metric 100000 1000 255 1 1500
     network 132.1.45.0 0.0.0.255
     no auto-summary
     eigrp router-id 150.1.4.4

    ip access-list standard R5ETH
     permit 132.1.5.0 0.0.0.255
     permit 192.10.1.0 0.0.0.255

     

    that's all folks, i think that everyone should try to find its own best solution and then compare with the others, 

    it's incredible how the same problem can be solved in so many ways. [8-|] and honestly i don't know if it is correct because i did not checked yet the breakdowns,

    i'm stuck in the regexp task 5.4  [*-)]

     

     

  • federic0,

    Great solution. I've been racking my brain on this one for days. However, I was unable to get to 132.2.6.6 (VLAN 6) from most devices so I used your earlier idea on VLAN 5 and 52 to solve it. Basically I did the same thing you did on R4 but on R2 for VLAN 6 (I increased the AD for route 132.2.6.0). It seems now I can get to everything with the backup link up or down.

    router ospf 1
     distance 171 0.0.0.0 255.255.255.255 R6VLAN6
    !
    ip access-list standard R6VLAN6
     permit 132.2.6.0 0.0.0.255

    Thanks for the ideas!

    Vin

     

  • I was also drowned inside this task for a couple of days and finally made it work.

    My goal was to make the implementation simple and picked a "one size fits all" method.  I think the distance manipulation is very confusing (at least to me) so I decided to use tagging.  Basically, redis into EIGRP from other protocols shouldn't be a problem since it will stop the routing loop with differentiated internal and external ADs.  Going into OSPF is the problem therefore I put tagging on both R2 and R3 to stop those EIGRP routes (that already redis into OSPF) from going back into EIGRP.  On R4 I just did regular bidirectional redis without tagging.  This is because when link between R3/R5 is down, EIGRP AS 10 becomes separated therefore R4 would need to learn back those EIGRP routes from OSPF for reachability.  When the link between R3/R5 is up, R4 is isolated from the EIGRP AS and only takes routes from within OSPF therefore no issues with mutual redis with EIGRP on R4 since this is inactive anyway.

    I have full reachability to every subnet with this method.  Later on with task 6.2 that multicast would need to prefer path from R1 to R2, I just put a new line into R2's route-map (which I used for tagging) to manipulate the metric of 150.1.2.2 route (from EIGRP) while redis into OSPF.

    My method may not be the best but it worked for me to get those @#$% three points !

Sign In or Register to comment.