Just wondering if anyone has run into these messages:
BGP-3-NOTIFICATION: sent to neighbor x.x.x.x passive 6/0 (CEASE: unknown subcode) 0 bytes
BGP-5-ADJCHANGE: neighbor x.x.x.x passive vpn vrf BLAH Down Error during connection collision
I've not had much luck trying to look these up. Also, when doing a sho ip bgp vpnv4 vrf BLAH nei, I see:
Last reset 1d19h, due to Active open failed
Basically the iBGP session establishes, I can see each side advertising routes, but neither side shows they are receiving any routes, the hold down expires and the session comes right back up, and the same thing over and over.
Basicaly, I'm just hoping someone has seen these messages before and might be able to give a little bit of info or a pointer to a good explanation of them. Thanks for any info - chris
This is the state where BGP peers exchange open messages which contains Basic parameters of the BGP peers before it goes into established state neighbour-ship.
This means your TCP is active but the neighbour is not reaching open confirm state due to lack of basic parameters not being received during open message exchange & therefore not reaching the established state.
A BGP notification message indicates an error in the neighbour ship adjacency establishment.
Can you make sure there is no congestion or a sudden link failure that could result in this issue.
Thanks for the responses. I do not believe it is a misconfiguration, nor a link failure. This is on a direct connection between 2 4500x-32, and I have 6 other BGP connections in 3 vrfs that are fine.
This iBGP session itself was fine. We upgraded software in early December and that's when this started. And it is just this one link in the one vrf. There are similar iBGP connections (between the same 2 4500x-32s) in the other 2 vrfs that are fine.
I think what I am going to end up doing is completely stripping out this neighbor definition and try reconfiguring. At any rate, I appreciate that advice. Good explanations and pointers to documentation.
thanks - chris
The peering address of this neighbour - can you confirm-
- Are you peering directly or indirectly to it?,
- If indirectly do you have NLRI to it? - Can you ping it or are you missing the update-source command,(sourcing address needs to be the same for all peers)
- Perform a extended from SIP to DIP of the peering addressing from either router?
I did a little more troubleshooting on this, but didn't really make any headway. I think I am going to have to open a case on this. The topology is really just between 2 4500x in a multivrf environment. There are 3 vrfs (default and 2 others). The other 2 vrfs have an iBGP link between these 3 4500s and those are stable. The link in question does come up, and I can see via the neighbor advertised-routes command that the routes getting advertised. But when I use the neighbor received-routes command, it shows 0.
showing the neighbor, the session is established. Everything looks normal with it except that the neighbors are showing they're not receiving routes even though the neighbor is advertising.
And the kicker to this is that this was up and stable before a reboot to upgrade software on them. We went from IOS-XE3.4.2 to XE3.6.1, mainly for BFD support. Nothing topology wise changed, but ever since the reboots this link, and only this link, has been problematic.
I've attached the output of the sho neighbor in case anyone might be able to notice something. But this makes no sense to me because all other links, including the 2 iBGP links in the other vrfs, on these 2 switches are good. There is another pair of 4500Xs on the remote side, set up the same way, and underwent the same software upgrade, and all BGP sessions on those are good. I am at a complete loss as to why it is just this one out of so many.
This may help you.
A. This message occurs when there is another BGP session already established. The router that receives the cease message has tried to send a BGP OPEN message to the same peer on another IP. This message is cosmetic and is due to a misconfiguration.
Link : http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/5816-bgpfaq-5816.html#error
i know its not my thread but this is the right answer
i have had the same problem
the reason was creating more than one session between the same neighbors after deleting the duplicated destination the log stopped.
I had same problem in BGP,
Reason is if you have configured multiple bgp neigh command for same as in one router and same is not configure in another router would create problem. This could be because BGP trying to connect to same AS irrespective of any IP. So you need to be careful while configuring commands and no unused command should be there for neigh peering.