BGP Hold time expired and no supported AFI/SFI

rameshprabhu · ‎05-24-2016

Hi all,

Please help me to fix this problem, BGP hold time expires frequently even though the cellular link signal strength is very good. Also, why would that AFI error appears which makes the BGP session down.

Config of DMVPN hub and spoke has been shared, and BGP is running through the encrypted link.

Logs:-

*May 24 14:26:11.518: %BGP-5-ADJCHANGE: neighbor 172.25.2.1 Up
*May 24 15:05:55.137: %BGP-3-NOTIFICATION: received from neighbor 172.25.0.1 4/0 (hold time expired) 0 bytes
*May 24 15:05:55.137: %BGP-5-NBR_RESET: Neighbor 172.25.0.1 reset (BGP Notification received)
*May 24 15:05:55.137: %BGP-5-ADJCHANGE: neighbor 172.25.0.1 Down BGP Notification received

*May 24 15:12:04.349: %BGP-3-NOTIFICATION: received from neighbor 172.25.2.1 active 2/8 (no supported AFI/SAFI) 3 bytes 000000
*May 24 15:12:04.349: %BGP-5-NBR_RESET: Neighbor 172.25.2.1 active reset (BGP Notification received)
*May 24 15:12:04.349: %BGP-5-ADJCHANGE: neighbor 172.25.2.1 active Down BGP Notification received
*May 24 15:12:04.349: %BGP_SESSION-5-ADJCHANGE: neighbor 172.25.2.1 IPv4 Unicast topology base removed from session BGP Notification received

Spoke Config:-

m-quest-sa-blakeview-r02#sh run int tu100
Building configuration...

Current configuration : 441 bytes
!
interface Tunnel100
description ***Primary DMVPN tunnel for QUEST to MINCHINBURY-DC-PRIMARY Hub Router***
ip address 172.25.1.249 255.255.254.0
no ip redirects
ip nhrp map multicast 172.16.0.2
ip nhrp map 172.25.0.1 172.16.0.2
ip nhrp network-id 1
ip nhrp nhs 172.25.0.1
no snmp trap link-status
tunnel source Cellular0
tunnel mode gre multipoint
tunnel key 1
tunnel protection ipsec profile QUEST-3G-DMVPN-PROFILE shared
end

m-quest-sa-blakeview-r02#sh run int tu200
Building configuration...

Current configuration : 443 bytes
!
interface Tunnel200
description ***Secondary DMVPN tunnel for QUEST to QUESTCOLO-DC-PRIMARY Hub Router***
ip address 172.25.3.249 255.255.254.0
no ip redirects
ip nhrp map 172.25.2.1 172.16.0.26
ip nhrp map multicast 172.16.0.26
ip nhrp network-id 2
ip nhrp nhs 172.25.2.1
no snmp trap link-status
tunnel source Cellular0
tunnel mode gre multipoint
tunnel key 2
tunnel protection ipsec profile QUEST-3G-DMVPN-PROFILE shared
end

m-quest-sa-blakeview-r02#sh run | s bgp
router bgp 65549
bgp log-neighbor-changes
network 10.157.10.0 mask 255.255.255.0
network 10.157.10.32 mask 255.255.255.224
network 10.157.10.64 mask 255.255.255.224
network 10.157.10.112 mask 255.255.255.240
network 10.157.10.128 mask 255.255.255.192
network 10.157.10.192 mask 255.255.255.240
neighbor 172.25.0.1 remote-as 64606
neighbor 172.25.0.1 description ** eBGP Primary DMVPN tunnel to MINCHINBURY-DC-PRIMARY**
neighbor 172.25.0.1 ebgp-multihop 20
neighbor 172.25.0.1 timers 7 21
neighbor 172.25.0.1 soft-reconfiguration inbound
neighbor 172.25.0.1 weight 200
neighbor 172.25.0.1 route-map 3G-WAN-OUT out
neighbor 172.25.2.1 remote-as 64604
neighbor 172.25.2.1 description ** DMVPN tunnel to QUESTCOLO-DC-PRIMARY**
neighbor 172.25.2.1 ebgp-multihop 20
neighbor 172.25.2.1 timers 7 21
neighbor 172.25.2.1 soft-reconfiguration inbound
neighbor 172.25.2.1 weight 100
neighbor 172.25.2.1 route-map 3G-WAN-OUT out
m-quest-sa-blakeview-r02#

Hub 1 with Tu100 Config:

MINCHINBURY-DC-PRIMARY#sh run int tu100
Building configuration...

Current configuration : 371 bytes
!
interface Tunnel100
description DMVPN Hub for QUEST BRANCHES
ip address 172.25.0.1 255.255.254.0
no ip redirects
ip mtu 1400
ip nhrp map multicast dynamic
ip nhrp network-id 1
ip tcp adjust-mss 1336
no snmp trap link-status
tunnel source GigabitEthernet0/1
tunnel mode gre multipoint
tunnel key 1
tunnel protection ipsec profile QUEST-3G-DMVPN-PROFILE
end

MINCHINBURY-DC-PRIMARY#sh run | s bgp
router bgp 64606
bgp router-id 172.16.0.2
bgp log-neighbor-changes
network 0.0.0.0
neighbor 172.25.1.249 remote-as 65549
neighbor 172.25.1.249 peer-group eBGP-DMVPN-Tunnel
neighbor 172.25.1.249 description **BGP Primary Peer to m-quest-sa-blakeview-r02 **
end
!

Vinit Jain · ‎05-24-2016

Hello,

how frequent is your BGP session getting flapped. Are you seeing the flap happening every 3 minutes? Could you please share the below output from both the Hub and the Spoke location.

- show ip bgp neigh <neighbor-ip>

Regards

Vinit

Thanks
--Vinit

rameshprabhu · ‎05-24-2016

Hi ,

Frequency is irregular, however at times it happens in 3minutes interval too.

Attached the output,

regards, Ramesh.

Vinit Jain · ‎05-24-2016

Could you please configure ip mtu to 1400 on the Spoke routers. Also, i see the BGP timers are different between the hub n the spoke router. COuld you please rectify the same.

Please let me know the result after following the above two steps.

Regards

Vinit

Thanks
--Vinit

rameshprabhu · ‎05-25-2016

I suppose the timers are same, and i've configured ip mtu 1400 on spoke now.

I will check for a day and let you know, however do you think this would fix both the errors?

In hub I've a peer group with timer set as same:-

neighbor eBGP-DMVPN-Tunnel peer-group
neighbor eBGP-DMVPN-Tunnel ebgp-multihop 20
neighbor eBGP-DMVPN-Tunnel timers 7 21
neighbor eBGP-DMVPN-Tunnel send-community
neighbor eBGP-DMVPN-Tunnel soft-reconfiguration inbound
neighbor eBGP-DMVPN-Tunnel route-map RM-IPVPN-3GLINK-WAN-OUT out

regards, Ramesh

Vinit Jain · ‎05-25-2016

was not aware of the peer-group config. most of the times, the MTU mismatch causes the session to flap at continuous intervals. So, this may possibly fix ur hold timer expiry issue.

Vinit

Thanks
--Vinit

Vinit Jain · ‎05-26-2016

Hello Ramesh

Has the BGP session remained stable after modifying the MTU?

Regards

Vinit

Thanks
--Vinit

rameshprabhu · ‎05-26-2016

Hi vinit

I've tried putting ip mtu 1400 on both tu100 and tu200 interface in 2 devices, however 1 of the devices did generated holdtime expiry error and session dropped.

The other one works fine still, any particular reason to use 1400?

Also, I've used ip tcp adjust-mss 1336 as well on 3rd device along with ip mtu 1400 and found the link to be stable. (no errors yet)

let me check which command fixes those 2 errors. please share ur comment too.

Thanks, Ramesh.

rameshprabhu · ‎05-29-2016

Hi Vinit

Here is the update, I've configured it on 25th May with below commands and errors did appeared in the timelines as mentioned below.

Please share your Comment, thanks.

m-quest-qld-tingalpa-r02#sh run int tu100 | i mtu|tcp
ip mtu 1400
ip tcp adjust-mss 1336
-------------------------------------------------------------------------
*May 25 18:09:16.435: %SYS-5-CONFIG_I: Configured from console by source on vty0 (2.4.0.63)

May 25 20:02:11.443: %BGP-3-NOTIFICATION: sent to neighbor 172.25.0.1 4/0 (hold time expired) 0 bytes

*May 26 15:56:16.928: %BGP-3-NOTIFICATION: sent to neighbor 172.25.0.1 4/0 (hold time expired) 0 bytes

*May 27 05:46:09.363: %BGP-3-NOTIFICATION: sent to neighbor 172.25.2.1 4/0 (hold time expired) 0 bytes

*May 27 18:24:10.007: %BGP-3-NOTIFICATION: sent to neighbor 172.25.0.1 4/0 (hold time expired) 0 bytes

*May 27 18:25:20.666: %BGP-3-NOTIFICATION: sent to neighbor 172.25.0.1 4/0 (hold time expired) 0 bytes

*May 27 18:30:20.695: %BGP-3-NOTIFICATION: sent to neighbor 172.25.2.1 4/0 (hold time expired) 0 bytes

*May 29 04:16:41.273: %BGP-3-NOTIFICATION: sent to neighbor 172.25.0.1 4/0 (hold time expired) 0 bytes

*May 30 06:40:30.315: %BGP-3-NOTIFICATION: sent to neighbor 172.25.0.1 4/0 (hold time expired) 0 bytes

rameshprabhu · ‎06-01-2016

Hi Vinit,

Still finding the same,

*Jun 1 13:48:10.037: %BGP-3-NOTIFICATION: received from neighbor 172.25.2.1 active 2/8 (no supported AFI/SAFI) 3 bytes 000000
*Jun 1 13:48:10.037: %BGP-5-NBR_RESET: Neighbor 172.25.2.1 active reset (BGP Notification received)
*Jun 1 13:48:10.037: %BGP-5-ADJCHANGE: neighbor 172.25.2.1 active Down BGP Notification received
*Jun 1 13:48:10.037: %BGP_SESSION-5-ADJCHANGE: neighbor 172.25.2.1 IPv4 Unicast topology base removed from session BGP Notification received
*Jun 1 13:48:10.209: %BGP-5-NBR_RESET: Neighbor 172.25.2.1 passive reset (Peer closed the session)
*Jun 1 13:48:10.213: %BGP-5-ADJCHANGE: neighbor 172.25.2.1 passive Down AFI/SAFI not supported
*Jun 1 13:48:18.129: %BGP-5-ADJCHANGE: neighbor 172.25.2.1 Up

*Jun 2 02:03:59.404: %BGP-3-NOTIFICATION: sent to neighbor 172.25.0.1 4/0 (hold time expired) 0 bytes
*Jun 2 02:03:59.404: %BGP-3-NOTIFICATION: sent to neighbor 172.25.2.1 4/0 (hold time expired) 0 bytes
*Jun 2 02:03:59.404: %BGP-5-NBR_RESET: Neighbor 172.25.0.1 reset (BGP Notification sent)
*Jun 2 02:03:59.404: %BGP-5-NBR_RESET: Neighbor 172.25.2.1 reset (BGP Notification sent)
*Jun 2 02:03:59.404: %BGP-5-ADJCHANGE: neighbor 172.25.0.1 Down BGP Notification sent
*Jun 2 02:03:59.404: %BGP_SESSION-5-ADJCHANGE: neighbor 172.25.0.1 IPv4 Unicast topology base removed from session BGP Notification sent
*Jun 2 02:03:59.404: %BGP-5-ADJCHANGE: neighbor 172.25.2.1 Down BGP Notification sent
*Jun 2 02:03:59.404: %BGP_SESSION-5-ADJCHANGE: neighbor 172.25.2.1 IPv4 Unicast topology base removed from session BGP Notification sent
*Jun 2 02:04:11.712: %BGP-5-ADJCHANGE: neighbor 172.25.2.1 Up
*Jun 2 02:04:11.740: %BGP-5-ADJCHANGE: neighbor 172.25.0.1 Up

ปลาวาฬทราย RMUTT CPE IX · ‎09-08-2016

I found logs:

Sep 8 14:17:15: %BGP-5-NBR_RESET: Neighbor a:b:9024:28::9931:1 passive reset (BGP Notification sent)
Sep 8 14:17:15: %BGP-5-ADJCHANGE: neighbor a:b:9024:28::9931:1 passive Down AFI/SAFI not supported!

My workaround:

Reconfigure BGP neighbor

paul driver · ‎05-25-2016

Hello

Just like to add also, It seems that the peering bgp ios doesn't support multisession, and their is a capability clash between the neighbours

Neighbor sessions:
1 active, is not multisession capable (disabled

You can negate this capability check by applying-

neighbour x.x.x.x dont-capability-negotiate

res

Paul

Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Vinit Jain · ‎05-25-2016

Yes, but the only downside is, the other capability negotitiations might also get disabled. since it is disabled on both the sides, it might not matter much but you can always configure neighbor <> transport single-session on both sides if the routers are not multi-session capable.

Regards

Vinit

Thanks
--Vinit

rameshprabhu · ‎05-25-2016

Hi

I'm not sure if AFI=2 in BGP is due to that, however I shall update that command tomorrow after seeing how the IP MTU 1400 command works in fixing the holdtime issue.

Thanks, Ramesh.

Ariam · ‎05-25-2020

Oi. Resolvi um problema semelhante a esse trocando a porta do link. Não esquecer de mudar no ospf também (caso necessário).