BIRD drops specific IPv6 session for no reason

[Stavros Konstantaras]

Hi Tapio,

Good point as well but I don’t have access to customer’s router. I can only touch my Linux server and based on that, ARP entry is there as the BGPv4 session remains up (which means that the switches in the middle can have a valid MAC entry in their MAC table). 

Only the BGPv6 session drops and when it drops, the log output does not really help:

Feb 20 21:46:11 rs1-mng bird6: 2001:7F8:1::A500:19:7727:1: Received: Hold timer expired
Feb 20 21:46:11 rs1-mng bird6: 2001:7F8:1::A500:19:7727:1: BGP session closed
Feb 20 21:46:11 rs1-mng bird6: 2001:7F8:1::A500:19:7727:1: State changed to stop
Feb 20 21:46:11 rs1-mng bird6: 2001:7F8:1::A500:19:7727:1: Down
Feb 20 21:46:11 rs1-mng bird6: 2001:7F8:1::A500:19:7727:1: State changed to down



Best regards,

Stavros Konstantaras | Sr. Network Engineer | AMS-IX 
M +31 (0) 620 89 51 04 | T +31 20 305 8999
ams-ix.net

> On 28 Feb 2020, at 14:08, Tapio Haapala <tapio.haapala at f-solutions.fi> wrote:
> 
> double check that your router have arp entry and route for that peer when that happens. Example if your router get wrong route for peer it can send response packets (or some cases arp requests) to wrong interface. So dump your another interfaces also at same time and you will see what it do. Probably watch for route and arp with proper grep and -n is also your friend if that happens very often. 
> 
> On 28/02/2020 13.41, Stavros Konstantaras wrote:
>> Hi Bird community,
>> 
>> We are investigating a weird customer issue regarding our Bird Route Servers (version 1.6.3) and a specific IPv6 session. Customer reports a sudden drop of his IPv6 session and -until now- we could not relate those drops with any issue or instability. Everything seems normal and no other customer complained at the moment of the incident. 
>> 
>> 
>> 
>> After some packet capturing at the moment of the event, we discovered that BIRD does not send a response messages to the customer’s BGP keepalive messages (see attached picture), which result to the BGP hold timer to expire and the sessions to be dropped. We observed this anomaly with both RSs but at different time slots and the tcpdump capture was running at the Interface were Bird is sending all BGP traffic for customers. At the moment of the event, we didn’t do any maintenance or other RS related work.
>> 
>> Has any of you experienced this in the past? If yes, how did you solve this?
>> Any related feedback is welcomed. 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Best regards,
>> 
>> Stavros Konstantaras | Sr. Network Engineer | AMS-IX 
>> M +31 (0) 620 89 51 04 | T +31 20 305 8999
>> ams-ix.net <http://ams-ix.net/> <http://ams-ix.net <http://ams-ix.net/>>
>> 
> 
> 
> -- 
> F-Solutions Oy
> 
> Tapio Haapala
> 
> PL7, 90571 Oulu
> GSM   +358400998371
> Skype burner-
> IRC   Burner at ircnet

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20200228/cce614c4/attachment.htm>