Troubleshooting BGP Neighbor Adjacency

Hello Tanmoy

The Local-AS feature is further described in this Cisco Documentation:

I hope this has been helpful! Stay safe and healthy!

Laz

Hi Laz ,

Awesome
Thank you very much

1 Like

I am confused on the multi-hop section. Why do we need to change the multi hop to “ebgp-multihop 2” if it’s a direct connection? Does the local int fas 0/0 on the router count as a hop?
ex. lo0 > int fas 0/0 > int fas 0/0 (remote router)

Hello Juan

Take a look at this post:

I hope this has been helpful!

Laz

Hello, I have a question: how often does it happen in a real BGP router that static routes are entered there? Furthermore: how often does it happen in a real BGP router that the loopback addresses or loopback networks between two routers are made known there?

Thanks in advance.

1 Like

Hello Roberto

BGP routers that are installed in a production network will often have static routes. It all depends upon the needs of a particular implementation. You will find that BGP routers on the edge of an enterprise network may need such configurations in order to function correctly, so it is not unusual to see.

Also, loopbacks are used very often for BGP routers in order to ensure that a BGP peering is not lost due to a downed interface. Loopbacks will remain up even if you have an interface that goes down, and this can maintain peerings in such an event. In order for this to function, you need to advertise the loopback interfaces so that routing can be established between them, which is a prerequisite for BGP peering.

You can find out more about this in the following lesson. The lesson may be about eBGP multihop, but it fully describes the requirements of loopbacks:

I hope this has been helpful!

Laz

you need to change the following at the very end to say “iBGP” instead of EBGP as you have taught us that EBGP has one hop dependency by default so you have typo there.

Problem solved! The only difference with EBGP is that we don’t have to change the TTL with the ebgp-multihop command.

Hello Brian

The example in section 4 of the lesson dealt with changing the source of the iBGP peering. In the example in section 2, he deals with a similar situation but with eBGP peering

What Rene is saying with his final statement there is that in the case of iBGP, you don’t need to change the TTL with the ebgp-multihop command as you do with the eBGP case.

Maybe the wording is not quite clear. Maybe a better wording would be:

Problem solved! The only difference here is that for iBGP peerings, we don’t need to change the TTL, whereas for eBGP we must use the ebgp-multihop command.

Does that make sense? I’ll let Rene know to clarify the wording.

I hope this has been helpful!

Laz

Hi Team,
Regarding below config , i want to know command that i need to run on my PE router to check uptime for CE router PNYC1064

address-family ipv4 vrf nacil_net
  redistribute static route-map SET-COMMUNITY-STATIC
  neighbor 57.214.87.128 remote-as 65000
  neighbor 57.214.87.128 description --- to CE ROUTER pnyc1064>>>>>>>>>>

Hello Bhupesh

To view the uptime of a Cisco router you must use the show version command. Within the output you will find the uptime of the device. It looks something like this:

Router# show version
Cisco Internetwork Operating System Software
IOS (tm) GS Software (RSP-JV-M), Experimental Version 11.1(12816)
[getchell 108]
Copyright (c) 1986-1996 by cisco Systems, Inc.
Compiled Mon 03-Jun-96 11:39 by getchell
Image text-base: 0x600108A0, data-base: 0x60910000
ROM: System Bootstrap, Version 5.3(16645) [szhang 571], INTERIM SOFTWARE
Router uptime is 4 minutes
System restarted by reload
> -- output omitted -- <

You can see that the system uptime shown above is 4 minutes. This command can only be run on the local device.

There is no way to determine the uptime of the neighboring device as you suggest. Even CDP doesn’t provide this information. Link Layer Discovery Protocol (LLDP) which is a vendor neutral link layer protocol like CDP, doesn’t contain this information by default, but does have the capability of creating custom Type Length Value (TLV) structures that can contain such information. But for your purposes, I think this is going overkill.

The only other thing you can do is to determine the uptime of the BGP neighborship. This will give you an idea of how long the other router has been a neighbor (and has thus been up and running).

You must monitor the BGP session in order to determine the neighbor peering uptime. This can be done by configuring the bgp log-neighbor-changes so that syslog messages will be logged whenever the peering goes up or down. Based on this, you can calculate the uptime. Alternatively, you can use SNMP to keep track of the status. More info can be found here:

I hope this has been helpful!

Laz

Hi Rene and Laz,
I’ve got a question about neighborships between loopbacks.
Why in case of Loopbacks neighborships in an IBGP environment we don’t have to change the bgp multihop ? What is the mechanism that avoids the TTL expiring in this kind of situations. As i’ve understood in a EBGP environment the LO interface is seen as an IP address that belongs to another device, that’s why it needs a second hop to reach it, isn’t it ?
Thanks for a feedback
Have a nice day
Aronne

Hello Aronne

By definition, iBGP peerings (that is, BGP peerings between routers in the same AS) don’t have to be directly connected. There is no such requirement. They just have to be reachable. That means that all iBGP routers in an AS must have fundamental routing between them already established either using an IGP or static routing. Therefore there is no restriction on what the TTL must be.

However, eBGP peerings (that is, BGP peerings between routers in different ASes) by default must be directly connected. If you are using loopback then yes, as you correctly stated, the loopback interface is seen as an IP address that is not directly connected, but is one or more hops away, and that is why a “second hop” is needed to reach it. Indeed, you can create eBGP peerings between eBGP routers that are several hops away if you choose to, but this should not be common practice. Does that make sense?

I hope this has been helpful!

Laz

Clear and great, as always !

Thanks Laz

1 Like

Hi Team,

Actually we are using solar winds and need to clear alerts. And why BGP peers are down even when interface tunnels are up. How to make them up. If I try to bounce the alerts then we will get alerts on tunnels. So, how should I make them up here? Thanks

Regards
Srikar

Hello Sonti

There could be several reasons why your BGP peers are down even when your interface tunnels are up. Here are a few troubleshooting steps:

  • Check the BGP configurations: Make sure the configurations on both ends of the BGP peer are correct. This includes checking the neighbor IP, AS numbers, and any applied BGP policies.
  • Check the reachability: Even if the tunnel interfaces are up, it doesn’t necessarily mean that the BGP neighbors can reach each other. Try pinging the BGP neighbor’s IP to verify.
  • Check BGP status: Use commands like show ip bgp summary to check the BGP status. This can show if the BGP session is established or if it’s stuck in a certain state.
  • Check for any recent changes: Any recent changes in the network could affect the BGP sessions. This includes changes in routing, firewall rules, or BGP configurations.

You may find some more detailed information on troubleshooting BGP neighbor adjacencies at the following lesson:

Without any more context or information about your particular setup, we are unable to give you any more specific suggestions to resolve your issue. With some more info, we may be able to provide you with some additional insight into resolving the issue.

As for clearing alerts in SolarWinds, you can acknowledge the alert which will remove it from the ‘Active Alerts’ view. To do this, go to the ‘Active Alerts’ page, select the alert, and click ‘Acknowledge’. Alternatively, you can also clear alerts by resolving the issue that triggered the alert.

I hope this has been helpful!

Laz