This may be timing related or an actual situation I need to handle.
run_neighbor_loop uses Tokio's tcp try_read_buf to get the initial TCP payload so we can determine the packet type and neighbor.
There was a TCP stream that came in where the message header of the NEXT BGP message came in the tail end of an Open message.
e.g. message header - open message - message header and beginning of next BGP message.
From a TCP perspective I can see how that is probably valid behavior and I need to handle the parsing of the message and saving of the partial next message. I just wasn't expecting it since I had not encountered it in our app yet.
Notice below the stream was 76 bytes but the message is 57 bytes.
Generating event AutomaticStartWithPassiveTcpEstablishment for all neighbors
TCP server started on port 179
TCP connection established from 10.0.0.23
Validated neighbor IP is in configured neighbors
Extracted neighbor from hashmap
Generated Event::TcpCRAcked
Moving neighbor to async task and executing run_neighbor_loop
Handling event AutomaticStartWithPassiveTcpEstablishment in state Idle
Moving to Active
Handling event TcpCRAcked in state Active
Preparing to send Open
Sent Open
Moving to OpenSent
Read 76 bytes from the stream.
Data read from the stream: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 39 01 04 00 01 00 B4 C0 A8 C8 01 1C 02 06 01 04 00 01 00 01 02 02 80 00 02 02 02 00 02 02 46 00 02 06 41 04 00 00 00 01 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 13 04
Message type is Open
Error: Message(
UpdateMessageLenAndIdxMismatch,
), skipping message [
255,
255,
255,
255,
255,
255,
255,
255,
255,
255,
255,
255,
255,
255,
255,
255,
0,
57,
1,
4,
0,
1,
0,
180,
192,
168,
200,
1,
28,
2,
6,
1,
4,
0,
1,
0,
1,
2,
2,
128,
0,
2,
2,
2,
0,
2,
2,
70,
0,
2,
6,
65,
4,
0,
0,
0,
1,
I suspect some delay in the app starting caused this, but it does reveal a valid scenario I need to handle.
This may be timing related or an actual situation I need to handle.
run_neighbor_loop uses Tokio's tcp try_read_buf to get the initial TCP payload so we can determine the packet type and neighbor.
There was a TCP stream that came in where the message header of the NEXT BGP message came in the tail end of an Open message.
e.g. message header - open message - message header and beginning of next BGP message.
From a TCP perspective I can see how that is probably valid behavior and I need to handle the parsing of the message and saving of the partial next message. I just wasn't expecting it since I had not encountered it in our app yet.
Notice below the stream was 76 bytes but the message is 57 bytes.
I suspect some delay in the app starting caused this, but it does reveal a valid scenario I need to handle.