TCP retransmission takes care of resending the dropped TCP segments. This is why the BGP peer remains up despite intermittent packet loss.
If you want to troubleshoot this issue, you have to find the common point of all the observed failures, i.e. how do BGP sessions where the issue is reported differ from those where the issue is not reported: are they all established through the same line card; same interface; if the affected BGP peer have peering with other routers, do they also report invalid md5 digest; etc.
If the common point of all failures is the router on which the error is reported, you can always open a service request with Cisco TAC.
XR-vm - CLI's
look for any process crash, review time stamp[if it is too old, then no immediate action needed]
verify if standby state is Ready and NSR-Ready
show proc cpu | exclude " 0%"
It's been a long standing ask for XR to support conditional route advertisements in BGP.
The expected option of using the
option in RPL currently can only be used at the default-inf...
On IOS-XR, Quality of Service has an extension to WRED (Weighted Random Early Detection) called Explicit Congestion Notification (ECN). ECN will mark packets instead of dropping them when the average queue length exceeds a specific threshold value. When c...
Technical Guide to Pre-Defined NAT.
In traditional NAT, due to the government regulations logging the CGN translations is mandatory and this is a huge cost incurrence. In Pre-defined NAT, the translations are known upfront, hence there is no nee...