Question regarding BGP

mrblackmamba343mrblackmamba343 Inactive Imported Users Posts: 136
All three routers are in BGP 65535. Router 1 is advertising its loopback and router2 is configured as a route reflector server for R3. I still see an invalid next hop in R3 BGP table after I configured R2 to also server as a next-hop-self to R3. Why?

Comments

  • Forsaken_GAForsaken_GA Member Posts: 4,024
    You're missing a route somewhere. Find out where.
  • mrblackmamba343mrblackmamba343 Inactive Imported Users Posts: 136
    You're missing a route somewhere. Find out where.

    I agree that using an IGP like a OSPF or even basic static routes can resolve this, but I want to use 100% iBGP. Is it possible? I do not want to run any other routing protocols
    BTW I was able to get this working by running OSPF but I'm curios as to why an IGP has to be run inorder to get this working
  • Forsaken_GAForsaken_GA Member Posts: 4,024
    I agree that using an IGP like a OSPF or even basic static routes can resolve this, but I want to use 100% iBGP. Is it possible? I do not want to run any other routing protocols
    BTW I was able to get this working by running OSPF but I'm curios as to why an IGP has to be run inorder to get this working

    Ok, so identify which route is missing, and then find out why BGP isn't propagating it -

    Remember that one of the key principles of BGP is that before it will propagate a route, it *must* have that route already in the table from some other method. After all, it doesn't make sense to advertise a route to a peer if I can't reach that route myself. And before BGP will install a BGP learned route into the routing table, it must have a route to the next hop. After all, it doesn't make sense to insert a route who's next hop I can't recurse to in the routing table.

    And it's technically possible to make iBGP work without an IGP, but it's kind of foolish to do so, it takes alot of administrative overhead. BGP isn't intended for use as an IGP, so trying to make it behave like one is usually not a good idea.

    Go look at R3, see what it has for the next hop to R1's loopback, and then go see if that next hop is in the routing table.
  • Forsaken_GAForsaken_GA Member Posts: 4,024
    And I just labbed this up, there's no special voodoo required here, no IGP, and no static routes configured. You've made a configuration assumption, which has led to a configuration mistake.

    If you're getting an invalid next hop, it means that the next hop isn't reachable. Which means the next hop is either incorrect, or you're missing a route to it.

    I'm betting that if you have R2 advertise the link between R1 and R2 into BGP, your issue will resolve itself.

    The question is can you figure out why?
  • mrblackmamba343mrblackmamba343 Inactive Imported Users Posts: 136
    Sure advertising the link between R1 and R2 will resolve this since it will make R3 have a route to the next-hop it could not previously reach(192.168.15.1). I thought BGP was smart enough to correct the next-hop without advertising anything...Well I guess I was wrong
  • Panzer919Panzer919 Member Posts: 462
    Every network that needs to be propagated, including interconnecting IP's should be put into BGP.

    One other thing to keep in mind, if you add a network into BGP and also add a mask, do not assume BGP will propagate those routes that are inside of that subnet. For instance, if you have a loopback of 10.0.0.1/30 but in BGP you are advertising 10.0.0.0 mask 255.0.0.0. It wont work and I had to find it out the hard way when one of our sites tried to fall back to our BGP link but that one /32 route wasn't advertised, caused SRST not to work and about half an hour to figure it out.
    Cisco Brat Blog

    I think “very senior” gets stuck in there because the last six yahoos that applied for the position couldn’t tell a packet from a Snickers bar.

    Luck is where opportunity and proper planning meet

    I have not failed. I've just found 10,000 ways that won't work.
    Thomas A. Edison
  • Forsaken_GAForsaken_GA Member Posts: 4,024
    Sure advertising the link between R1 and R2 will resolve this since it will make R3 have a route to the next-hop it could not previously reach(192.168.15.1). I thought BGP was smart enough to correct the next-hop without advertising anything...Well I guess I was wrong

    It's not a matter of protocol intelligence, but protocol design. BGP's design says that the Next Hop Attribute only changes at AS border crossings, otherwise it's preserved. That's why applying next-hop-self to an iBGP neighbor doesn't do any good if all you have are iBGP connections.

    iBGP is intended to use an IGP for internal reachability. There's a reason why the AD on iBGP routes is incredibly high. It's not because Cisco thinks RIP is a better protocol.

    As far as why that's so.....

    What method does BGP use for loop avoidance?

    What attribute does not get updated when propagated through iBGP?

    If you're relying on iBGP to function as your IGP, you're playing with fire. This is also why a number of other iBGP restrictions exist, like the split-horizon rule.
Sign In or Register to comment.