BGP- peer being deleted

[Henry Hu]

BGP2025/01/13 11:47:42 BGP: %BGP-5-ADJCHANGE: neighbor 10.192.145.25 Up

2025/01/13 11:47:31 BGP: %BGP-5-ADJCHANGE: neighbor 10.192.145.25 Down Peer being deleted

2025/01/13 11:47:07 BGP: %BGP-5-ADJCHANGE: neighbor 10.192.145.25 Down Peer being deleted

I got above logs from customer, but I never seen any BGP logs like this---Peer being deleted.

What does that mean? Can I assusme BGP message already reached another end(link was not down), but due to some reason, for example, there might be planned maintenance and BGP configuration was deleted for period of time from another end?

Not sure about that.

Thanks

BR

[MHM Cisco World]

Moslty this log is remote peer use different AS Than what you config under your bgp. 

also it can from soft/hard reset.

Run 

Debug bgp events <<- 

MHM

[David Ruess]

You might be able to debug BGP messages. Usually, a notification is sent to tear down a peer (Notification = Bad). It may be more descriptive of why the peer is being torn down. Maybe the remote side initiated it through commands or as you said maintenance.

Were the peers up for a while before these messages or have the peers ever established?

-David

[Henry Hu]

Yes, it's already under production, so BGP was working fine and under monitoring.

It was down for around 10 minutes, and that kind of logs keeps poping up during this period of time.

[MHM Cisco World]

 show logging <<- if you config logging buffer it can give us some hint why peer dead for 10 min

show ip bgp neighbor x.x.x.x <<- share this

MHM

[Henry Hu]

 Thanks for your advice, unfortunately, the router is managed by our customer.

This kind of log is really rare.never seen it before ： ）

[MHM Cisco World]

I will send you PM tomorrow 

MHM

[paul driver]

Hello
Usually this is seen when as your the bgp peering is torn/shutdown or becomes incorrect in some way, either its lost its tcp connection due to some kind of transit communication being incurred or negated. or the neighbour was just simply  shutdown down, but again you should also see the reason for that torn down session but again this depends on what rtr you are seeing in the logs on.
As stated by others the peering would be also deleted IF you have configured the bgp process or peering in the wrong AS however that would be accompanied with a mai-formatted neighbour reset reset.stating wrong AS  or active reset which I dont believe this has happened in your case.as it wasnt a new peering g but an existing peering

What you show is more than likely logged from the rtr that is acting as the  bgp server . (local port 179.

Check with either of the following commands
sh bgp ipv4 unicast neighbors 10.192.145.25  host|Last rest
sh ip bgp neighbors 10.192.145.25  host|Last rest

note: if you have any Mal-formatted messages  please use this url to assist in the debugging.

Edited:
For clarification i have just quickly performed a validation of what I have just stated, by suspending the communication between a bgp server and client

sh bgp ipv4 unicast neighbors 100.1.1.2 | in Last reset|host
Last reset never
Local host: 100.1.1.1, Local port: 179

*Jan 13 20:31:07.163: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel100, changed state to down
*Jan 13 20:31:20.344: %BGP-3-NOTIFICATION: sent to neighbor *100.1.1.2 4/0 (hold time expired) 0 bytes
*Jan 13 20:31:20.350: %BGP_SESSION-5-ADJCHANGE: neighbor *100.1.1.2 IPv4 Unicast topology base removed from session Neighbor deleted
*Jan 13 20:31:20.351: %BGP-5-ADJCHANGE: neighbor *100.1.1.2 Down BGP Notification sent

[Richard Burts]

I generally look at log messages and assume that they are presented from oldest to newest (reading from top to lower entries). But looking at the time stamps in this post I note that the first post (neighbor up) is the most recent and the other messages about peer being deleted are older. So the peer was down/deleted and then was re-established.

I wonder if there were other messages in the log that might shed light on this? 

If we knew more about this environment and especially about the BGP configuration we might be able to offer better advice.