BGP Authentication issue, normal behavior?

ferrivero · ‎08-16-2012

Hello guys,

Can you please let me know if this is a normal BGP behavior or not? We were implementing a new BGP session with a new customer. We got this messages but after that (without making any changes on the config) the session came automatically up.

Aug 15 19:00:32.900 UTC: %BGP-5-ADJCHANGE: neighbor x.x.x.x vpn vrf xx-xx Down Peer closed the session

Aug 15 19:00:32.900 UTC: %BGP_SESSION-5-ADJCHANGE: neighbor x.x.x.x IPv4 Unicast vpn vrf xx-xx topology base removed from session Peer closed the session

Aug 15 19:00:41.412 UTC: %BGP-3-NOTIFICATION: received from neighbor x.x.x.x active 2/5 (authentication failure) 0 bytes

Aug 15 19:00:41.416 UTC: %BGP_SESSION-5-ADJCHANGE: neighbor x.x.x.x IPv4 Unicast vpn vrf xx-xx topology base removed from session BGP Notification received

Aug 15 19:00:55.748 UTC: %BGP-3-NOTIFICATION: received from neighbor x.x.x.x active 2/5 (authentication failure) 0 bytes

Aug 15 19:00:55.752 UTC: %BGP_SESSION-5-ADJCHANGE: neighbor x.x.x.x IPv4 Unicast vpn vrf xx-xx topology base removed from session BGP Notification received

Aug 15 19:01:05.988 UTC: %BGP-3-NOTIFICATION: received from neighbor x.x.x.x active 2/5 (authentication failure) 0 bytes

Aug 15 19:01:05.992 UTC: %BGP_SESSION-5-ADJCHANGE: neighbor x.x.x.x IPv4 Unicast vpn vrf xx-xx topology base removed from session BGP Notification received

Aug 15 19:01:20.324 UTC: %BGP-3-NOTIFICATION: received from neighbor x.x.x.x active 2/5 (authentication failure) 0 bytes

Aug 15 19:01:20.324 UTC: %BGP_SESSION-5-ADJCHANGE: neighbor x.x.x.x IPv4 Unicast vpn vrf xx-xx topology base removed from session BGP Notification received

Aug 15 19:01:33.636 UTC: %BGP-3-NOTIFICATION: received from neighbor x.x.x.x active 2/5 (authentication failure) 0 bytes

Aug 15 19:01:33.636 UTC: %BGP_SESSION-5-ADJCHANGE: neighbor x.x.x.x IPv4 Unicast vpn vrf xx-xx topology base removed from session BGP Notification received

Aug 15 19:01:43.876 UTC: %BGP-3-NOTIFICATION: received from neighbor x.x.x.x active 2/5 (authentication failure) 0 bytes

Aug 15 19:01:43.880 UTC: %BGP_SESSION-5-ADJCHANGE: neighbor x.x.x.x IPv4 Unicast vpn vrf xx-xx topology base removed from session BGP Notification received

Aug 15 19:01:53.092 UTC: %BGP-3-NOTIFICATION: received from neighbor x.x.x.x active 2/5 (authentication failure) 0 bytes

Aug 15 19:01:53.096 UTC: %BGP_SESSION-5-ADJCHANGE: neighbor x.x.x.x IPv4 Unicast vpn vrf xx-xx topology base removed from session BGP Notification received

Aug 15 19:02:01.772 UTC: %BGP-5-ADJCHANGE: neighbor x.x.x.x vpn vrf xx-xx Up

We know the config is correct as we have been using it for many other customers, but this time we saw this messages. Should I worry about anything on the config on customer end or is it ok to see this messages when the session first try to stablish?

Thanks!

Deepak Ambotkar · ‎08-17-2012

Hi Rivero,

Your customer must have had authentication set earlier when you got those error messages and he would have found that BGP is failing because of authentication error, he disabled the authentication and kept plain BGP.So your BGP auth error msgs went away. I think you should consider this normal.

Regards,

Deepak

Alessio Andreoli · ‎08-17-2012

Hi Fernando,

keep in mind that even if you do NOT configure authentication an authentication process takes place anyway. The method will be "NULL" but it will still authenticate it. You should even check that no spaces are left after your authentication config. One space represents a character and it may be the cause of this peer relationship to fail.

A quick step could be to configure a new authentication writing the code on notepad and pasting it on the router. This, of course, caring about spaces and correct MD5 string.

Hope this helps

Alessio

ferrivero · ‎08-17-2012

Thanks guys for your answers!!!

But let me show you one more thing. We actually have authentication enable on both ends and it was always enabled. The configs were not changed and the session went up on its own. The password is a single word with no spaces on it.

address-family ipv4 vrf xx-xx

redistribute connected

neighbor x.x.x.x remote-as xxxx

neighbor x.x.x.x local-as xxxx no-prepend replace-as

neighbor x.x.x.x password 7 ***************

neighbor x.x.x.x timers 1 3

neighbor x.x.x.x activate

neighbor x.x.x.x inherit peer-policy CS-POL

neighbor x.x.x.x remove-private-as all

exit-address-family

My concern is to know if it is normal for BGP to fail the negotiation on the first couple tries and then succede. I've seen it over IPSEC but never over BGP.

Thanks

Alessio Andreoli · ‎08-17-2012

Hi Fernando,

try to take away the password obfuscation... or to check that is on both sides..

Alessio

ferrivero · ‎08-17-2012

Hi Alessio,

Thanks for your thoughts on this. I'm starting to believe that this a customer fault, they may have realized that password was wrong and quickly correct it.

Thanks all for your help on this