BGP Configuration

[lzakariya]

Hi,

I have a scenario as found in the attached. I have configured BGP on all the 4 router. I have given running configuration and show ip route details of all the routers. My problem is when I am pinging from R3 to to all the other router it is okay. But when i am pinging from R3 to R1, serial interfaces are pinging. but I cannot ping from R3 to R1 fa0/0 and vice versa. Also, from R3 LAN to R1 Lan and vice versa. But ping from R3 to R1( also R1 to R3) serial interfaces are okay. I can see routing table has entries to the LAN network of all the routers in all the router. But I dont know what is the issue in pinging from R3 LAN to R1 Lan and vice versa.

1. R1 cannot ping to R3 Lan

2. R3 cannot ping to R1 Lan

3. R1 can ping to all the other networks except R3 lan only

4. R3 can ping to all other networks except R1 lan only

5. R2 and R4 can ping to all the networks including R3 and R1 lans

[Mark Malone]

when devices are not directly connected in IBGP you need and underlying IGP

[dukenuk96 · Accepted solution]

Hi!

As Mark wrote, you need underlying IGP for iBGP to operate in the network shown in your diagram, but to tell the truth, there are few more options - you can achieve this by using static routes as well, or change next hop on every router to self. Totally you have 3 options:

1) IGP (most correct)
2) Static routes (easy to config, hard to support)
3) Change next hop to self (a bit tricky)

We can help you to correct the problem - choose the option and we will try to show you solution with some diagnostics and explanations. I recommnd Mark's suggestion - use IGP. While you'll be deciding, I will give some advice and diags of your current config.

R1, you configure:

router bgp 65001
 neighbor 192.168.1.82 remote-as 65001
 neighbor 192.168.1.89 remote-as 65001
 neighbor 192.168.1.93 remote-as 65001

So you rely iBGP TCP connection to physical interfaces - bad behavior in LANs - because if they fail, BGP session will fail too. Maybe you will want to create two peerings for each router (to s0/0 and s0/1 interfaces) - I also would not advise such overhead. Better build your BGP sessions on loopback interfaces which are always up and running - easier to configure, less overhead, easier to diagnose.

Also actually R1 do not form stable neighborship with R3, you must see same things in your logs:

R1#
*Jul 15 14:50:11.598: %BGP-5-ADJCHANGE: neighbor 192.168.1.89 Down BGP Notification sent
*Jul 15 14:50:11.598: %BGP-3-NOTIFICATION: sent to neighbor 192.168.1.89 4/0 (hold time expired) 0 b ytes
R1#
*Jul 15 14:50:11.599: %BGP_SESSION-5-ADJCHANGE: neighbor 192.168.1.89 IPv4 Unicast topology base rem oved from session  BGP Notification sent
*Jul 15 14:50:12.280: %BGP-5-ADJCHANGE: neighbor 192.168.1.89 Up

It happens because R1 does not have stable route to R3's networks, you can try even to ping R3's serial interface IP addresses - it will fail from time to time. If you wish to go deeper, I can explain why, but try self :) I will provide some diagnostics - compare timers and routing descriptors - I think it will bring some thoughts to you:

R1#sh ip ro 192.168.1.89
Routing entry for 192.168.1.88/30
  Known via "bgp 65001", distance 200, metric 0, type internal
  Last update from 192.168.1.89 00:03:00 ago
  Routing Descriptor Blocks:
  * 192.168.1.89, from 192.168.1.89, 00:03:00 ago
      Route metric is 0, traffic share count is 1
      AS Hops 0
      MPLS label: none
R1#sh ip ro 192.168.1.89
Routing entry for 192.168.1.88/30
  Known via "bgp 65001", distance 200, metric 0, type internal
  Last update from 192.168.1.93 00:00:00 ago
  Routing Descriptor Blocks:
  * 192.168.1.93, from 192.168.1.93, 00:00:00 ago
      Route metric is 0, traffic share count is 1
      AS Hops 0
      MPLS label: none
R1#
*Jul 15 14:56:22.820: %BGP-5-ADJCHANGE: neighbor 192.168.1.89 Down BGP Notification sent
*Jul 15 14:56:22.820: %BGP-3-NOTIFICATION: sent to neighbor 192.168.1.89 4/0 (hold time expired) 0 bytes
R1#
*Jul 15 14:56:22.820: %BGP_SESSION-5-ADJCHANGE: neighbor 192.168.1.89 IPv4 Unicast topology base removed from session  BGP Notification sent
*Jul 15 14:56:23.530: %BGP-5-ADJCHANGE: neighbor 192.168.1.89 Up