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
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : [email protected]
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
