Question regarding BGP

mrblackmamba343

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?

Forsaken_GA

You're missing a route somewhere. Find out where.

mrblackmamba343

Forsaken_GA wrote: »

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_GA

mrblackmamba343 wrote: »

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_GA

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?

mrblackmamba343

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

Panzer919

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.

Forsaken_GA

mrblackmamba343 wrote: »

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.