Task 5.5 impacts 5.4

Section 5.5 requires a conditional advertisement on R2 that states that R2 only sends R5 the 136.1.29.0/24 prefix when the PPP link to R3 is down.

Section 5.4 states that the BGP table needs to see the 136.1.29.0/24 prefix from R2.

With both of these configurations applied the only way that the 5.4 remains accurate is if the PPP link between R2 and R3 is shut down. So if everything is up/up then the 5.4 solution will not be valid.

Thoughts?

Comments

  • The solution to 5.4 also produces output that looks different to the sample in the lab book. To get the output listed we need to filter from the next hop 136.1.15.1.

    I agree that the 5.5 solution will stop you seeing output anything like that required in 5.4.

    This raises an interesting question. Do your solutions need to work as required at the end of the lab, or do they only need to work as per the point you were at in the lab? If they need to work at the end of the lab, then you need to leave the R2-R3 link shut down. But this violates 5.5 asking for traffic to route over that link.

    I set the weight high on both the 136.1.15.1 and 136.1.245.2 next-hops, then used AS-PATH prepending for 5.5, that way I get an output that is similar to 5.4 and the routing behaviour required.
  • but the solution-guide is different...
    why they use conditional advertising?
  • It may be caused by AS-PATH prepending can't make sure ALL TRAFFIC pass through ppp rather then FR link, but conditional advertising does.
  • but what would be the solution?as per my understanding all tasks must be in working condition at the end of the lab,as no one can validate if the task was working when one finished it
  • I personally think this was contrived to teach a lesson. In 5.4, we made absolute certain that R5 had a weight of 100 via R2. Then in 5.5, we override that such that AS200 must route via AS100 if the HDLC link is available. In the task description of 5.5 it is said that the "administrators of AS 200 have not been cooperating..." This we know because we were very recently that administrator, setting weight to 100, which is at the top of the path selection heap. What 5.5 shows is that even that can be overridden via conditional advertisement.

    I don't think we would get a task quite like this in the real lab but it's not impossible. The grading script could simply check to see if you had properly configured R5 to weight the route to 100 but that R5 was routing towards R1 to get to VLAN29 in spite of that weight.

    My thoughts...

  • Dear All,

    Kindly clarify one thing regarding task 5.5 that why they used conditional advertisement in solution guide ? We can do this task using AS path prepending.


    Thanks & Regards,

    Mujeeb
  • Task 5.5 had to use conditional advertising because:

    1) AS Path prepending doesn't work as R5 has set a weight to prefer the Frame Relay link. So regardless of how many times AS300 tried to prepend, traffic will always go from R5 to R2 via the FR link.

    2) Sending a summarised route out from R2 to R5 won't work either as it would absolutely break task 5.4.

    So we are down to conditional advertising.
  • I spent lots of minutes before I understood that conditional network _must_ be seen in 'sh ip bgp' , not only in 'sh ip route'.
Sign In or Register to comment.