Issues with BGP NEXT_HOP_SELF

millworx

SO currently studying BGP for the ROUTE exam. Fired up a little GNS3 Lab.

IN AS5500 I have 4 routers interconnected via different subnets over ethernet for redundancy, using OSPF. The ASBR is connected to AS 6500. They are passing routes no problem.

I created a loopback on the ASBR to talk to the iBGP peer which is not directly connected, (also created the loopback on the iBGP peer). They talk no problem.
Router 2 I issue a neighbor 4.4.4.4 next-hop-self command
Router 4 now shows the routes are valid... but whenever i try to ping all I get is destination unreachable.

Heres the topology.



Also notice there seems to be some routing loop. in OSPF when issuing a traceroute it keeps bouncing back and forth between the same routers before finally finding the route. I disabled router 3 just to see if the potential loop was causing a problem with the BGP route. NO Success.

All routers are Running 12.4(25c) so Its not a sycnh issue.

All OSPF routers have connectivity, so for sake of truncating this already long post I will just ost the configs for R2 and R4 (the two iBGP routers).

ROUTER2

interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
interface FastEthernet0/0
 ip address 10.1.1.2 255.255.255.0
 duplex auto
 speed auto
!
interface Serial0/0
 ip address 192.168.1.1 255.255.255.0
 encapsulation ppp
 clock rate 2000000
!
interface FastEthernet0/1
 ip address 10.1.4.2 255.255.255.0
 duplex auto
 speed auto
!
interface Serial0/1
 no ip address
 shutdown
 clock rate 2000000
!
router ospf 1
 log-adjacency-changes
 network 2.2.2.2 0.0.0.0 area 0
 network 10.1.1.2 0.0.0.0 area 0
 network 10.1.4.2 0.0.0.0 area 0
!
router bgp 5500
 no synchronization
 bgp log-neighbor-changes
 neighbor 4.4.4.4 remote-as 5500
 neighbor 4.4.4.4 update-source Loopback0
 neighbor 4.4.4.4 next-hop-self
 neighbor 192.168.1.2 remote-as 6500
 no auto-summary

ROUTER4

interface Loopback0
 ip address 4.4.4.4 255.255.255.255
!
interface FastEthernet0/0
 ip address 10.1.2.4 255.255.255.0
 duplex auto
 speed auto
!
interface FastEthernet0/1
 ip address 10.1.3.4 255.255.255.0
 duplex auto
 speed auto
!
router ospf 1
 log-adjacency-changes
 network 4.4.4.4 0.0.0.0 area 0
 network 10.1.2.4 0.0.0.0 area 0
 network 10.1.3.4 0.0.0.0 area 0
!
router bgp 5500
 no synchronization
 bgp log-neighbor-changes
 neighbor 2.2.2.2 remote-as 5500
 neighbor 2.2.2.2 update-source Loopback0
 no auto-summary

SORRY for the long post. I am just trying to understand why iBGP is not working, despite R4 showing *> on the show ip bgp summ and installing the path in the routing table.

networker050184

Does the destination have a route back to the source IP you are pinging from? Thats the number one issue I see people having when they start on BGP. The router is going to use the out going interface address as the source by default. Most people aren't advertising those transit link addresses into BGP.

It will also help if you let us know what you are pinging and tracing to.

millworx

Sorry about that. I am trying to ping from Router 4 to the 50.1.1.1 address which is on Router 1 in the other BGP AS

Router 2 and Router 4 can ping each others loopbacks. (which they are using to communicate over iBGP)

Router 2 is connected to Router 1 via eBGP and can successfully ping 50.1.1.1

Router 1 has no direct relationship with Router 4, it should be reaching it via router 2...

millworx

oh i feel like an idiot... lol Im wasn't redistributing the OSPF routes back to R1

networker050184

You really don't need the OSPF routes on R1 if you want it to simulate a real world set up. What you will want is to source your pings from a BGP advertised network.

Forsaken_GA

It doesn't look like you have AS5500 actually originating any routes in BGP. So if AS6500 is sending routes into AS5500, R2 would propagate them to R4, since you're using next hop self, R2 has a valid next hop to the networks advertised.

However, if you're not sending any networks to AS6500, it has no idea how to respond to it.

Ex, if you're pinging from 4.4.4.4, R2 would properly pass that on to R1, but unless you're advertising a route for 4.4.4.4 from R2 to R1, R1 has no valid route to respond with.

If you're redistributing your IGP into BGP, this is a big no no. You do not want to expose your internal routes to an external peer.

Originate a route for 4.4.4.4 on R4 and then source the ping from that interface, and you'll see that it'll probably succeed without you needing to redistribute routes.

Not originating routes is another common mistake for beginners with BGP, just because you have a BGP session up, doesn't mean you're automatically sending out routes.

yebo2010

Hello Millworx,
It seems to me that the problem is you need a statement on both routers indicating that the neighbor is some hops away(multihop problem) i.e:

R2:
#neighbor 4.4.4.4 ebgp-multihop 2

R4:
#neighbor 2.2.2.2 ebgp-multihop 2

Hope that helps.

yebo2010

Though it is acceptable when practicing for the exam to have such kind of set up, it is totally unacceptable in reality. BGP is evil for the small to medium networks(And iBGP makes it even worse).

The only reason I would be compelled to implement iBGP is when I have multiple ISP connections.

BGP was designed for inter AS connectivity.

But its OK for your purpose, I have created similar set ups myself before.

deth1k

First of all you need a full mesh iBGP within yourAS5500 otherwise traffic to AS6500 will be blackholled i.e IGP doesnt know anything about your external networks and will be droped at R5 or R3 or you'd have to redistribute BGP into OSPF. Also you are not advertising any networks from AS5500 to AS6500 therefore it will not know what to do with traffic originated outside of its AS apart from directly connected interfaces/networks.

deth1k

yebo2010 wrote: »

Hello Millworx,
It seems to me that the problem is you need a statement on both routers indicating that the neighbor is some hops away(multihop problem) i.e:

R2:
#neighbor 4.4.4.4 ebgp-multihop 2

R4:
#neighbor 2.2.2.2 ebgp-multihop 2

Hope that helps.

How did you get your CCNP? Why would he need ebgp next-hop when he is running ibgp and peering using loopbacks which are advertised into OSPF process.

Forsaken_GA

yebo2010 wrote: »

Hello Millworx,
It seems to me that the problem is you need a statement on both routers indicating that the neighbor is some hops away(multihop problem) i.e:

R2:
#neighbor 4.4.4.4 ebgp-multihop 2

R4:
#neighbor 2.2.2.2 ebgp-multihop 2

Hope that helps.

Look at his configs dude. The R2 to R4 connections are iBGP, not eBGP. Not being directly connected to each other is fine, the IGP carries the transport.

I'm willing to bet his entire probably is pretty much that he's not originating any routes to AS6500. So naturally when R4 tries to ping, it's going to fail, because AS6500 has no valid path to respond with. He mentioned the external network showing up in his show ip bgp table on R4 in the initial post, so I think he has his BGP sessions up and exchanging routes internally. And it appears he has his external neighbor originating routes into AS 5500. He just seems to have forgotten that pings are bi-directional and they need a valid route back to actually work. A simple and easy mistake to make for a beginner

Forsaken_GA

Actually, I'm retarded. The lack of origination for routes is an issue, yes, but yeah, the internal routing is an issue as well. Either R3 and R5 need to be brought into iBGP, a link needs to be brought up between R2 and R4, or the routes need to redistributed into OSPF.

Or R2 needs to be sending a default route to the other OSPF routers

deth1k

Don't forget that R1 doesn't have any routes from AS5500 (you are not advertising any networks to it looking at your BGP configs). Also your OSPF routers R3 and R5 don't know anything about BGP routes and will drop any traffic from R4 destined to network you are advertising from R1. Like i previously said you have two options 1st one being the best is to run iBGP on all of the routers (full mesh) or 2nd - to redistribute BGP into OSPF.

Forsaken_GA

deth1k wrote: »

Don't forget that R1 doesn't have any routes from AS5500 (you are not advertising any networks to it looking at your BGP configs). Also your OSPF routers R3 and R5 don't know anything about BGP routes and will drop any traffic from R4 destined to network you are advertising from R1. Like i previously said you have two options 1st one being the best is to run iBGP on all of the routers (full mesh) or 2nd - to redistribute BGP into OSPF.

R2 distributing a default route into the OSPF domain works as well (I was curious, so I labbed this up real quick), that will allow R3 and R5 to forward the traffic for the BGP routes, and is generally ok, as long as R2 remains the only egress point from the AS.

millworx

Thanks Foresaken, I figured it out eventually. Took me a few days to wrap my whole head around BGP and its complexities especially integrating it with an IGP. But finally started getting the hang of it. Took about 3 days break from the book and just did straight labbing with different topology configurations.

One thing I'm wondering about, lets say the original topology I posted above had R4 as an egress point as well, so both R2 and R4 were connected to different ISPs. How would I go about setting it up for failover in OSPF.

Im assuming I would setup two default routes and redistribute those into OSPF, that way if one router fails it automatically shuffles over to the other router connected to the other ISP? Am I correct in this understanding?

Forsaken_GA

millworx wrote: »

One thing I'm wondering about, lets say the original topology I posted above had R4 as an egress point as well, so both R2 and R4 were connected to different ISPs. How would I go about setting it up for failover in OSPF.

Im assuming I would setup two default routes and redistribute those into OSPF, that way if one router fails it automatically shuffles over to the other router connected to the other ISP? Am I correct in this understanding?

Pick up Sam Halabi's book Internet Routing Architectures, he addresses scenarios like this. Labbing up his different scenarios is a very good way to learn BGP.

Letting R4 advertise a default route would work as well, just make sure it's assigned a higher AD than the one R2 is putting out. That would let the OSPF routers switch over automatically. Whenever you're employing multiple default routes, though, there are design considerations.

Read Halabi's book, it's not terribly large, and it's worth your time and money

millworx

Thanks for the suggestion, just ordered a copy from amazon!

yebo2010

deth1k wrote: »

How did you get your CCNP? Why would he need ebgp next-hop when he is running ibgp and peering using loopbacks which are advertised into OSPF process.

Do I really need to justify how I got my CCNP? I dont think so!

The ebgp multihop command works whether it be for ibgp or ebgp(there is no alternative form for ibgp since ebgp multihop was desined for ebgp, ibgp sessions carries TTL = 255 versus TTL = 1 in eBGP). Infact that is the simplest way of forming a mesh within the ibgp network topology presented.

The only problem that I have noticed with my solution is that the peering is through loopback address hence hopcount may be more than I specified.

I dont see a problem of loopbacks being advertised into OSPF because multihop requires a route to the peering router so INDEED OSPF has to be there for the mesh to occur. REMEMBER you can have a mesh without having directly connectedness.

Thanks for your observations.

deth1k

yebo2010 wrote: »

Do I really need to justify how I got my CCNP? I dont think so!

The ebgp multihop command works whether it be for ibgp or ebgp(there is no alternative form for ibgp since ebgp multihop was desined for ebgp, ibgp sessions carries TTL = 255 versus TTL = 1 in eBGP). Infact that is the simplest way of forming a mesh within the ibgp network topology presented.

The only problem that I have noticed with my solution is that the peering is through loopback address hence hopcount may be more than I specified.

I dont see a problem of loopbacks being advertised into OSPF because multihop requires a route to the peering router so INDEED OSPF has to be there for the mesh to occur. REMEMBER you can have a mesh without having directly connectedness.

Thanks for your observations.

The command was and is designed for eBGP as the name suggests it is rendered useless in iBGP implementations since loopbacks are always advertised into IGP.

APA

yebo2010 wrote: »

The ebgp multihop command works whether it be for ibgp or ebgp(there is no alternative form for ibgp since ebgp multihop was desined for ebgp, ibgp sessions carries TTL = 255 versus TTL = 1 in eBGP)

You're surely pulling everyones little johnson right?

if the command is prefixed eBGP multihop... why on earth would you use it for iBGP?

iBGP doesn't have the concept of 'forcing' a peer to be directly connected.... therefore you don't need multihop, ttl-security or any other of the hacks that you can implement to bypass the eBGP rule of having a eBGP peer directly connected, when trying to bring up an iBGP peering session.

All you have to ensure is that the peering address for an iBGP session is reachable in both directions....(bidir)