Activity log for bug #2040001

Date Who What changed Old value New value Message
2023-10-20 17:15:17 Tiago Pires bug added bug
2023-10-20 17:24:38 Tiago Pires description When using NDR, the speaker's current behavior is to work in ACTIVE mode which will not create a local TCP socket on TCP 179 port. Therefore, in the switch's BGP session, it needs to be configured as passive. Operators could have a switch brand that does not follow correctly the RFC 4271 regarding with the BGP FSM (8.2). When the NDR and the switch has a health BGP session, the Operator could run a maintenance window in the switch or in the NRD and the session could flap and go down for while and on the switch side, the BGP session state can change to IDLE. According to RFC 4271, when a BGP session is in IDLE state, it refuses all inbound BGP connection attempts, and starts a TCP connection to the peer(NDR) and NDR will not answer because it is in ACTIVE mode and has no listen port for this. And if the switch correctly follow the RFC regarding BGP passive mode when enabled, it will ignore it and accept the incoming connection from the NDR and the connection will be restablished. That is definitely a switch-side issue but when having this situation, we could have an NDR option that could create a BGP peer using the connect mode as CONNECT_MODE_BOTH and open the local TCP socket on the TCP 179 port in order to anwser incomming TCP connections. This sounds like an RFE for me and I would like to hear your thoughts. When using NDR, the speaker's current behavior is to work in ACTIVE mode which will not create a local TCP socket on TCP 179 port. Therefore, in the switch's BGP session, it needs to be configured as passive. Operators could have a switch brand that does not follow correctly the RFC 4271 regarding with the BGP FSM (8.2). When the NDR and the switch has a health BGP session, the Operator could run a maintenance window in the switch or in the NRD and the session could flap and go down for while and on the switch side, the BGP session state can change to IDLE. According to RFC 4271(8.2.2.), when a BGP session is in IDLE state, it refuses all inbound BGP connection attempts, and starts a TCP connection to the peer(NDR) and NDR will not answer because it is in ACTIVE mode and has no listen port for this. And if the switch correctly follow the RFC regarding BGP passive mode when enabled, it will ignore it and accept the incoming connection from the NDR and the connection will be restablished. That is definitely a switch-side issue but when having this situation, we could have an NDR option that could create a BGP peer using the connect mode as CONNECT_MODE_BOTH and open the local TCP socket on the TCP 179 port in order to anwser incomming TCP connections. This sounds like an RFE for me and I would like to hear your thoughts.
2023-10-20 18:00:41 James Troup bug added subscriber James Troup
2023-10-20 19:48:06 Brian Haley tags l3-bgp
2023-10-24 19:36:01 Roberto Bartzen Acosta tags l3-bgp l3-bgp rfe
2023-10-26 23:39:14 Miguel Lavalle neutron: status New Triaged
2023-10-26 23:39:18 Miguel Lavalle neutron: importance Undecided Wishlist
2023-10-26 23:41:00 Miguel Lavalle neutron: assignee Tiago Pires (tiagohp)
2023-10-27 19:07:03 OpenStack Infra neutron: status Triaged In Progress
2023-11-10 15:02:37 Brian Haley tags l3-bgp rfe l3-bgp rfe rfe-approved