in BGP topology in lab 40, R4 cannot ping R1

[simon italy]

In CCNP Lab 040: Border Gateway Protocol Lab in the book 101 LAB CISCO

after making the configuration, in task 3 "Task 3: 
Advertise the 150.x.x.x LAN subnets on all routers via BGP. These should be injected
using the network command on all routers. Verify that all routers’ LAN subnets can ping
every other routers LAN subnet. Use an extended ping to perform this verification." , during the verification R4 cannot ping R1 and R2 , just ping R3 which is directly connected with R3 ?!

[MHM Cisco World]

Use redistrubte connect under bgp and check again 

MHM

[M02@rt37]

Hello @simon italy 

So you check BGP state between R1-R3 and R1-R2 ?

[Royalty]

Hi @simon italy,

If everything else is working and this is your only symptom

• R4 LAN cannot ping the LANs of R1 and R2 (and vice versa, e.g., R1 cannot ping R4's LAN, but can ping everything else)

I am going to assume everything else is configured correctly and that all BGP peerings are up between the routers and that you have verified the network statements exist on each one (and that the LAN interfaces are up):

You are running into the issue, which I'm not sure of its official name, but basically routes that are advertised between two iBGP peers do not, by default, change the next-hop. What happens is that when R3 receives routes from R1 and R2, it inserts them into the BGP table. These routes are then advertised towards R4 over the iBGP peering. However, iBGP has a special condition where it does NOT change the next-hop address of routes that have been learnt from eBGP peers. R3 then passes the route to R4 but leaves the next-hops as 10.0.0.5 and 10.0.0.9. But, can R4 reach those next-hops? It can't.

If this is your problem you can fix it by doing redistribute connected as mentioned by MHM. This will redistribute all connected subnets into BGP. You would need to do 'redistribute connected' on R3. R4 would then know how to reach the directly connected routes of R3. Alternatively, and I think this is what the lab wants you to do since it says to use the 'network' command, is use next-hop-self. Next-hop-self is a command that goes under an additional neighbor statement and informs R3 that when passing routes to any iBGP neighbor, change the next-hop to itself. The lab doesn't say you cannot use redistribute connected, so either method will work. In summary, try this:

• On R3:

router bgp 3
redistribute connected

OR:

• On R3:

router bgp 3
neighbor 10.0.0.14 next-hop-self

Edit:

Just to add some more information that may be of help, but only if the above is actually the problem. I may have gone on an assumption tangent!: Try researching NWLLA OMNI as BGP best path selection. If you look on R4 you should see all BGP table routes from R1, R2, R3 LAN subnets. But, they will show up with r> which is RIB failure. It means the 'N' in the above is failing, like BGP does a check to make sure the next-hop is reachable. If it is not reachable, the packet cannot enter the RIB. No RIB entry, no FIB entry, packet forwarding on R4 says to drop

[gayangee]

Dear Friend,

Are you trying this using the Cisco Packet Tracer & Cisco Packet tracer Not Support the iBGP Connections. you can define R4 also another Remote-AS then its work fine.

[shambhu.kumar]

Configure next-hop self in R3 toward R4 (ie 10.0.0.14)