We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is Why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career!
  • Full Access to our 588 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

 

314 New Members signed up the last 30 days!

satisfaction-guaranteed

100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!


Forum Replies

  1. Jon says:

    Hello @giorgiortavidze,

    Many thanks for your question. It is not necessary to configure next-hop-self on all iBGP routers and can have undesirable results. Any time we configure this we are modifying the original routes and modifying routes should always be done with care. Even better we try to avoid the need to modify routes by appropriate design choices.

    Next hop self is one possible solution if a router receiving the unmodified route would be unable to understand how to reach the specified next hop. Although we can modify the route in BGP, a common alternative is to provide the router with an additional piece of information about how to reach the specified next-hop, for example providing a static route to that next hop or having another routing protocol (such as OSPF) operating more locally sharing information about exit points from your network.

    If we apply next hop self by default a common issue is that traffic will flow but follow a sub-optimal path such as looping via a transit AS (it might be some remote branch site) rather than taking a more direct route with more bandwidth available. Connectivity can feel "slow" but not broken in this case.

    So you have several options you can design into your network. Have fun choosing!
    Kind regards,
    Jon

  2. Hello Brian

    It’s nice to see how you are working through the problem and we can “read your thoughts” along the way.

    So, having answered your own original question, here’s the question that I’ll try to answer:

    You must remember one of the fundamental laws of routing: If a route is successful in one direction, it does NOT mean that it will be successful in the other. So R3 was able to communicate with R2 and R1 the route to the 3.3.3.0 network. So it is possible for R1 to reach R3. This is the perspective or R1 since there is a route from R1 to 3.3.3.0. However, if you looked at the routing table of R3 (which you did) you will see that there is no route back to R1 without the appropriate network commands.

    So looking at the routing table in R1 only shows you that R1 can reach R3. It says nothing about R3 reaching R1. In order to determine that you’ll have to look at the routing table on R3.

    I hope this has been helpful!

    Laz

  3. OMG!

    So I can apply that rule to routes? Meaning as long as it can get there it will be added just not reachable because it knows how to get there but not the way back.

    That does make perfect sense…gosh… I should have thought about that or at least posed it as a question. I was thinking that it probably had to do with some rule I had learned at some point about TCP/IP and traffic movement but just didn’t think of what was right in front of me. I hate when I do that but that happens a lot lol…

    Ok now that makes sense and I can put it in a nice little box and label it lol… thanks!

  4. any thoughts on this ? Even I am wondering why it shows as valid route ?

35 more replies! Ask a question or join the discussion by visiting our Community Forum