yahoo-eng-team team mailing list archive

[Tiago <2040001@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

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.

** Affects: neutron
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/2040001

Title:
  [N-D-R] Change neighbor connect mode when the BGP peer does not
  support passive mode

Status in neutron:
  New

Bug 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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/2040001/+subscriptions