BGPaaS: BGP session from VM can fail sometimes
Bug #1533924 reported by
amit surana
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
Juniper Openstack | Status tracked in Trunk | |||||
R3.0 |
Fix Committed
|
High
|
Manish Singh | |||
Trunk |
Fix Committed
|
High
|
Manish Singh |
Bug Description
contrail 3.0-2697.
BGP peering to g/w IP and dns IP has been configured in the BGP VM. Both connections were up and routes were being sent. At some point, connection to g/w IP was torn down and subsequent SYN segments from the VM were dropped (Flow Queue Limit Exceeded). TCP connection to dns IP remained up and functional.
gcore is placed here: 10.84.5.
flows are also dumped in the above directory. 1.1.3.3 is the VM IP, 1.1.3.1 is g/w and 1.1.3.2 is the dns. 172.16.80.1/.3 are the two control nodes.
Debugged this further and found that the bug happens if the BGP VM goes away without actually FIN/RSTing the TCP flow. Now, if the VM tries to establish a new TCP connection to the same destination, the flow gets stuck in Hold state and packets are silently discarded.
The right way to handle this would be to forward the new SYN to the CN and updating the VM->vRouter side of the flow with the new source port. Once the SYN hits the CN, nne of the two scenarios would play out:
1. If syn.seq is in window, CN tcp stack will respond back with a RST. This RST should be forwarded to the VM.
or
2. if syn.seq is out of the window, the CN tcp stack will respond back with an ACK (in an attempt to resynchronize the client). The BGP VM on seeing this ACK will RST the connection (doesn't expect ACK with wrong seq in SYN-sent state), which should be forwarded back to the CN. The RST.seq will be the same as ACK.ack, and so the CN tcp state will be cleaned up.
Either way, the idea is to end up synchronizing the source and destination hosts on the state of the TCP flow; in this case, it should be to abort the old flow and start a new one. After scenario 1/2 plays out, the BGP VM will be able to successfully setup a new peering session with the CN on the next attempt.