BGP Blackhole sighting?

mguy

I'm really new with BGP and have fumbled my set-up.



I have a iBGP R3 peer that cannot ping the destination as advertised by eBGP R5
Scenario:
I ping from R5: ping 50.1.1.1. and it fails..

On R3 (correction) we see a path to 50.1.1.1

B 50.1.1.0 [200/0] via 4.4.4.4, 00:05:31
4.0.0.0/32 is subnetted, 1 subnets
O 4.4.4.4 [110/21] via 10.1.13.2, 00:19:26, FastEthernet0/0
[110/21] via 10.1.12.2, 00:19:26, FastEthernet0/1

via 4.4.4.4 which is on the edge router R1

but R4 and R2 do not have iBGP running and R3 needs to traverse them to get into R1.
R3 and R1 on the other hand are IBGP peers

In the diagram I circled R4 and we see this
ICMP packet debugging is on
R4#
*Mar 1 00:18:08.547: ICMP: dst (50.1.1.1) host unreachable sent to 10.1.12.1
R4#
*Mar 1 00:18:10.555: ICMP: dst (50.1.1.1) host unreachable sent to 10.1.12.1
R4#
*Mar 1 00:18:12.595: ICMP: dst (50.1.1.1) host unreachable sent to 10.1.12.1
R4#
*Mar 1 00:19:49.055: ICMP: dst (50.1.1.1) host unreachable sent to 10.1.12.1
R4#
*Mar 1 00:19:51.111: ICMP: dst (50.1.1.1) host unreachable sent to 10.1.12.1
R4#
*Mar 1 00:19:53.127: ICMP: dst (50.1.1.1) host unreachable sent to 10.1.12.1

!! R4 doesn't even know 50.1.1.1 and how could it, it is not running iBGP!!

So I'm left wondering if I can ever get traffic between iBGP peers separated by non-IBGP peers.

But shouldn't the packets be routed to 4.4.4.4 instead to 50.1.1.1? but it's not doing that. I'm confused :::::

Then there's bit about using "no synchronization rule" so I turn them off on the iBGP peers and still nothing.
What does synchronization rule mean anyways????????

vishaw1986

Hey ,

Firstly are per your topology I assume that you have neighbourship between IBGP (R3-R1 ) , R1-R5 EPGP .

In this case your have to redistribute the routes on R1 into the IGP protocol to make the reachibilty .

BGP Synchronization :

go with this link BGP Synchronization

f0rgiv3n

Hey mguy, the first red flag that I'm seeing is that R5 has a route to get to 50.1.1.1 THROUGH R4 (4.4.4.4)... However, 50.1.1.1 lives on R5. Did you put "network 50.1.1.0 mask 255.255.255.0" on R4? You might have a loop if you have a static route for 50.1.1.0 -> 10.1.45.2 on R4 and are also putting that network (50.1.1.0/24) into BGP using the network command on R4.

You should only have R5 configured using the network command for network 50.1.1.0/24. Then R4 ->R3 neighbor needs to be configured with next-hop-self.

Then what will happen is R3 will see the network of 50.1.1.0/24 with the next hop of 4.4.4.4 (if your neighbors are built using update-source loopback 0). Then OSPF will take over because your R3 will know how to get to 4.4.4.4 via OSPF.

That's one direction of communication, now you need to figure out how to get R5 to learn that R4 is its next-hop for network 1.1.1.0/24(R1's Loopback)

mguy

I made correction to the post. That was R3's output.

I thought so too that OSPF would know how to route the packets to 50.1.1.1 through 4.4.4.4 but the non-peer router R4 sees the destination of 50.1.1.1 and does not know what to with it.

If the ICMP packets had a destination of 4.4.4.4 then it would forward, but 50.1.1.1 is not in it's routing table and dropped.

Also, I don't think it matters but I dont have redistribute or anything just cut and dry network BGP command propagating the 50.1.1.1

Nate--IRL--

All routers in the transit path must be running BGP and you'll need fully meshed iBGP peerings for those running iBGP.

Nate

mguy

Here I redid the lab to make it much simpler. R3 and and R1 are iBGP peers.

On R3 there's a loopback for the 1.1.1.0 /24 network

I run "sh ip bgp" on R1:
Network Next Hop Metric LocPrf Weight Path
*>i1.1.1.0/24 10.0.1.2 0 100 0 i

On R1s routing table:
1.0.0.0/24 is subnetted, 1 subnets
B 1.1.1.0 [200/0] via 10.0.1.2, 00:13:21
10.0.0.0/24 is subnetted, 2 subnets
C 10.0.0.0 is directly connected, FastEthernet0/0
O 10.0.1.0 [110/20] via 10.0.0.2, 00:22:25, FastEthernet0/0

Here we see the 1.1.1.0 is accessible via 10.0.1.2 and we se 10.0.1.0 was learned in OSPF

so I ping 1.1.1.1 in R3

but on the non-peer BGP R2, here is what I see

*Mar 1 00:24:11.367: ICMP: dst (1.1.1.1) host unreachable sent to 10.0.0.1
R2(config-router)#do debug ip icmp
*Mar 1 00:24:13.427: ICMP: dst (1.1.1.1) host unreachable sent to 10.0.0.1
R2(config-router)#do debug ip icmp
*Mar 1 00:24:15.467: ICMP: dst (1.1.1.1) host unreachable sent to 10.0.0.1
R2(config-router)#do debug ip icmp
*Mar 1 00:31:43.263: ICMP: dst (1.1.1.1) host unreachable sent to 10.0.0.1
R2(config-router)#do debug ip icmp
*Mar 1 00:31:45.307: ICMP: dst (1.1.1.1) host unreachable sent to 10.0.0.1
R2(config-router)#do debug ip icmp
*Mar 1 00:31:47.347: ICMP: dst (1.1.1.1) host unreachable sent to 10.0.0.1




Thoughts? R2 does not know 1.1.1.1 because it doesnt run iBGP.

mguy

Nate--IRL-- wrote: »

All routers in the transit path must be running BGP and you'll need fully meshed iBGP peerings for those running iBGP.

Nate

Is this accurate?

What's the point in peering iBGP neighbors seperated by non-iBGP routers if all the routers had to be running iBGP anyways?

Nate--IRL--

Either use the above or Redistribute BGP into the IGP (EDIT:- With Synchronisation)

Nate

vishaw1986

Reply to post 6 :

Hey to test this , enable synchronization on r1 ,
then u will see that r1 will not install the 1.1.1.0/24 in the BGP table untill it get the same route from the IGP . ====> Thats Synchronization

When u disable the synchronization R1 will install the 1.1.1.0/24 to the BGP table without checking the same route from an IGP .

So we redistribute the same route into the IGP network to make it reachable .

NetworkVeteran

Nate wrote:

All routers in the transit path must be running BGP and you'll need fully meshed iBGP peerings for those running iBGP.

mguy wrote: »

Is this accurate?

Mostly. There are exceptions beyond a CCNP paygrade if the transit traffic is somehow encapsulated, plus some trivia about enabling synchronization that was relevant a few ages ago.

What's the point in peering iBGP neighbors seperated by non-iBGP (transit) routers

That's his point--that config is pointless, except to learn the right way to do things.

networker050184

NetworkVeteran wrote: »

That's his point--that config is pointless, except to learn the right way to do things.

Yep this is the most common exercise used to show the pitfalls of BGP and how to get around them. Its not a realistic set up.

mguy

Was synchronization created because not all routers (back in the day I suppose) cannot handle BGP?

Cisco turned it off because they iBGP peers to be one hop of each other -- what's the reason for this?

mguy

With synchronization, bgp paths will not be installed in iBGP peer without learning from IGP first
With no-synchronization, bgp paths will be installed in iBGP regardless

In new routers,
no need to synchronize the path with an IGP first
..
cuz you will not design it this way anyways

(is accurate?)

Nate--IRL--

Yeah, basically you will always design in a full mesh for the iBGP peers, in doing so there is no need to use Synchronisation to avoid black holes.

IIRC in the past when the internet routing table was a fraction of its current size synchronisation was a feasible method to avoid black holes, these days the internet route table is far to large for this method.

Nate

networker050184

Nate--IRL-- wrote: »

Yeah, basically you will always design in a full mesh for the iBGP peers, in doing so there is no need to use Synchronisation to avoid black holes.

Hopefully you don't design that! That's what route reflectors are for, but I don't think that is covered in the current NP level material.

Nate--IRL--

networker050184 wrote: »

Hopefully you don't design that! That's what route reflectors are for, but I don't think that is covered in the current NP level material.

Perhaps the NP stuff is just the basics then, I'm not sure. RRs are touched upon briefly and Confederations are merely mentioned. For NP AFAIK Full-mesh is the design aimed for, as the scenarios demonstrated seem to involve 4 iBGP peers at most.

Nate