I have a working BGP session established. With "debug ip bgp events" I see many (2/3 every second) messages like this:
*Jul 23 11:23:48.773: BGP: default originate timer at max delay of 64 sec
*Jul 23 11:23:48.997: BGP: default originate timer at max delay of 64 sec
I can find nothing about this message. Can anyone tell me what is it?
IOS version is 12.4(24)T and platform is Cisco 2811
Interesting. Googling for that message didn't work for me, either.
Do you generate a default route in your BGP configuration, for a particular neighbor or in general?
Thankyou for your answer. There is more...
Today I have the router with the processor to 99%! I need to reboot, bgp session stuck in 'closed' state and with "clear ip bgp" nothing change.
This is not my first BGP configuration, but the first one with the latest IOS (I have a 32bit ASN with RIPE so I need to use this IOS).
My BGP configuration is:
router bgp 3.143
network 220.127.116.11 mask 255.255.248.0
neighbor 18.104.22.168 remote-as 1267
neighbor 22.214.171.124 ebgp-multihop 3
neighbor 126.96.36.199 update-source FastEthernet0/0
neighbor 188.8.131.52 soft-reconfiguration inbound
neighbor 184.108.40.206 route-map MYNETWORKS out
ip route 0.0.0.0 0.0.0.0 220.127.116.11
ip route 18.104.22.168 255.255.255.255 22.214.171.124
After the reboot BGP table works and processor is at 4%. During the table download I have many of this messages:
*Jul 24 10:12:05.247: BGP_Router: unhandled major event code 128, minor 0
*Jul 24 10:12:05.467: BGP_Router: unhandled major event code 128, minor 0
*Jul 24 10:12:05.735: BGP_Router: unhandled major event code 128, minor 0
*Jul 24 10:12:05.923: BGP_Router: unhandled major event code 128, minor 0
I attach 'debug ip bgp updates' and 'show process cpu | include BGP' and 'show ip bgp summary' it it helps.
Thank you for the additional information.
I do not see any obvious problem here, just a couple of subtle observations:
1.) Are you absolutely sure you need the command "neighbor 126.96.36.199 soft-reconfiguration inbound"? This command was necessary in times before RFC 2918 (September 2000) when there was no way how to ask a BGP peer to resend its RIB to us. However, this option effectively doubles the memory requirements of your BGP process and it is not necessary anymore, as all recent BGP routers implement the Route Refresh capability. You can check it yourself by issuing the command "show ip bgp nei 188.8.131.52" - look for a section similar to this:
Route refresh: advertised and received(old & new)
If this information is displayed, you can safely remove the "soft-reconfiguration inbound" command.
2.) It seems that your BGP peer is constantly announcing changes in its RIB database. You have a large churn in your BGP table - after your BGP neighbor was up just 8 minutes, the table revision jumped up to 289476 (assuming it started from 1). That's quite a lot. Is it normal for your BGP peer to send you so many changes? Is it perhaps possible to filter out unnecesary networks? Maybe you could also consider using the BGP Dampening feature.
3.) It is possible indeed that these problems may be caused by your version of IOS. That has to be confirmed by a Cisco TAC, however. Have you considered contacting them? And by the way, what IOS version are you using?
Peter, thankyou for your support. I'll follow you suggestion. I think that there is something related to 124-24.T IOS version in 2811 platform.
My solution for now is to have a partial BGP table sent from neighbors. I'll try the TAC way.
You are welcome. Please let us know if there is anything interesting coming out from the TAC support.
Perhaps I found the solution.
My provider connection is made with load-balancing between 4 SHDSL connections.
So I have four route like this:
ip route 0.0.0.0 0.0.0.0 dialer0
ip route 0.0.0.0 0.0.0.0 dialer1
ip route 0.0.0.0 0.0.0.0 dialer2
ip route 0.0.0.0 0.0.0.0 dialer3
for a problem in some data link interfaces the connection was lost for some periods.
But dialer interface are always up, so they remain in routing table, and there was packet loss.
Do you know, what is the cause of this message?
006423: .Jul 11 2012 11:58:18.652 PL: BGP_Router: unhandled major event code 128, minor 0
006424: .Jul 11 2012 11:58:19.444 PL: BGP_Router: unhandled major event code 128, minor 0
006425: .Jul 11 2012 11:58:19.904 PL: BGP_Router: unhandled major event code 128, minor 0
006426: .Jul 11 2012 11:58:20.336 PL: BGP_Router: unhandled major event code 128, minor 0
006427: .Jul 11 2012 11:58:21.056 PL: BGP_Router: unhandled major event code 128, minor 0
006428: .Jul 11 2012 11:58:21.380 PL: BGP_Router: unhandled major event code 128, minor 0
Unfortunately, I do not know. This seems to be an IOS internal issue. If nothing that has been discussed in this thread seems to also apply to you (and possibly work around this problem), I really suggest first trying upgrading to a newer IOS version, or if you have a TAC contract, contact the TAC with this issue and let them suggest a solution.
What IOS version are you running, anyway? On what platform? Perhaps if you could post your BGP configuration and the output of show ip bgp summary command we could at least find something that may seem "out of ordinary". It's a blind shot but nevertheless worth trying.
I have been getting same messages:
*Jul 7 00:06:00.955: BGP_Router: unhandled major event code 128, minor 0
In my case the problem was that I still have configured test vrf (I have ASR1001), so I guess even I removed BGP from test vrf as VRF was still configured it was scanning routing table on that VRF:
*Jul 7 00:05:59.581: BGP: topo test:MVPNv4 Unicast:base Scanning routing tables
Once I completely removed the test vrf I don't see these messages anymore.
So I expect ASR had allocated some memory for BGP and it was still somehow checking.