更改小于 19 和大于 4096 的 BGP 数据包大小
Changing BGP packet size less than 19 and greater than 4096
我正在 ubuntu 上使用 bgp 实现。我想在 bgp 数据包中做一些畸形，bgp 将我们的大小限制在 19 到 4096 之间，但是为了测试目的，我将大小更改为小于 19 和大于 4096。之后，当我将这个数据包从一秒发送到秒时，在两个发言者之间建立了 bgp 会话，第二个应该发送包含错误的通知消息：消息长度错误。
但我没有得到它，而是它在 wireshark 中显示格式错误的数据包，而且我无法在 wireshark 中打开该数据包。任何人都可以帮助我处理这种数据包畸形并获得通知错误。
仅供参考：我已经尝试了所有数据包，如打开、更新和保持活动。格式错误的打开数据包：
下面的更新答案
Wireshark 中显示的 BGP 数据包具有标记字段 (16 x ff)，后跟长度 16 (00 10)。
因此，这确实是您想要测试的场景：您的测试 BGP 扬声器发送了一个长度不正确的 BGP 数据包，而被测远程 BGP 扬声器应该通过发回带有错误代码的通知数据包来响应 "Message Header Error" 和错误 sub-code "Bad Message Length".
Wireshark 显示从测试仪 BGP 扬声器发送到被测 BGP 扬声器的格式错误的 BGP 数据包。 Wireshark 抱怨它是格式错误的 BGP 数据包是正确的：格式错误是因为长度无效。显然，Wireshark 并没有特别说明它不喜欢数据包的哪些方面。
您应该查看反向的 TCP 流（源 10.0.0.2 目标 10.0.0.1）并查找被测 BGP 发言者发回的 BGP NOTIFICATION 数据包。
更新的答案从这里开始
根据错误消息 ([Error] bgp_read_packet error: Connection reset)，您似乎正在测试 Free Range Routing，或者它的前身之一 Quagga 或 Zebra。
我重现了您正在测试的场景。
我是 运行 具有以下配置的自由范围路由 (FRR) BGP 发言人：
Current configuration:
!
frr version 7.1-dev-MyOwnFRRVersion
frr defaults traditional
hostname ip-172-31-31-121
log file /var/log/frr/debug.log
log syslog
service integrated-vtysh-config
!
debug bgp neighbor-events
!
router bgp 100
neighbor X.X.X.X remote-as 200
!
line vty
!
end
我使用下面的 Python 测试程序发送带有 "too short" header 的消息：
#!/usr/bin/env python3
import socket
BGP_IP = 'Y.Y.Y.Y'
SHORT_MSG = (b'\xff\xff\xff\xff\xff\xff\xff\xff' # First 8 bytes of marker
b'\xff\xff\xff\xff\xff\xff\xff\xff' # Last 8 bytes of marker
b'\x00\x10' # Length 16
b'\x01') # Open
def main():
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
print("Socket created")
sock.connect((BGP_IP, 179))
print("Socket connected")
sock.send(SHORT_MSG)
print("Short message sent")
while True:
data = sock.recv(1)
if data == b'':
print("Connection closed or reset")
break
print("Received:", data)
if __name__ == "__main__":
main()
将X.X.X.X替换为测试仪的IP地址，将Y.Y.Y.Y替换为被测BGP扬声器的IP地址。
在这种情况下，被测 BGP 扬声器确实发送了正确的 NOTIFICATION 消息。
这是 FRR 日志报告的内容：
2019/02/09 21:49:05 BGP: 172.31.17.121 [FSM] Timer (connect timer expire)
2019/02/09 21:49:05 BGP: 172.31.17.121 [FSM] ConnectRetry_timer_expired (Active->Connect), fd -1
2019/02/09 21:49:05 BGP: 172.31.17.121 [Event] Connect start to 172.31.17.121 fd 26
2019/02/09 21:49:05 BGP: 172.31.17.121 [FSM] Non blocking connect waiting result, fd 26
2019/02/09 21:49:05 BGP: bgp_fsm_change_status : vrf 0, established_peers 0
2019/02/09 21:49:05 BGP: 172.31.17.121 went from Active to Connect
2019/02/09 21:49:05 BGP: 172.31.17.121 [Event] Connect failed 111(Connection refused)
2019/02/09 21:49:05 BGP: 172.31.17.121 [FSM] TCP_connection_open_failed (Connect->Active), fd 26
2019/02/09 21:49:05 BGP: bgp_fsm_change_status : vrf 0, established_peers 0
2019/02/09 21:49:05 BGP: 172.31.17.121 went from Connect to Active
2019/02/09 21:49:08 BGP: [Event] BGP connection from host 172.31.17.121 fd 26
2019/02/09 21:49:08 BGP: bgp_fsm_change_status : vrf 0, established_peers 0
2019/02/09 21:49:08 BGP: 172.31.17.121 went from Idle to Active
2019/02/09 21:49:08 BGP: 172.31.17.121 [FSM] TCP_connection_open (Active->OpenSent), fd 26
2019/02/09 21:49:08 BGP: 172.31.17.121 passive open
2019/02/09 21:49:08 BGP: 172.31.17.121 Sending hostname cap with hn = ip-172-31-31-121, dn = (null)
2019/02/09 21:49:08 BGP: 172.31.17.121 sending OPEN, version 4, my as 100, holdtime 180, id 172.31.31.121
2019/02/09 21:49:08 BGP: bgp_fsm_change_status : vrf 0, established_peers 0
2019/02/09 21:49:08 BGP: 172.31.17.121 went from Active to OpenSent
2019/02/09 21:49:08 BGP: 172.31.17.121 bad message length - 16 for OPEN
2019/02/09 21:49:08 BGP: %NOTIFICATION: sent to neighbor 172.31.17.121 1/2 (Message Header Error/Bad Message Length) 2 bytes 00 10
2019/02/09 21:49:08 BGP: 172.31.17.121 [FSM] BGP_Stop (OpenSent->Idle), fd 26
2019/02/09 21:49:08 BGP: bgp_fsm_change_status : vrf 0, established_peers 0
2019/02/09 21:49:08 BGP: 172.31.17.121 went from OpenSent to Deleted
注意 "Bad Message Length" 消息。
测试程序报告如下：
Socket created
Socket connected
Short message sent
Received: b'\xff'
Received: b'\xff'
Received: b'\xff'
Received: b'\xff'
Received: b'\xff'
Received: b'\xff'
Received: b'\xff'
Received: b'\xff'
Received: b'\xff'
Received: b'\xff'
Received: b'\xff'
Received: b'\xff'
Received: b'\xff'
Received: b'\xff'
Received: b'\xff'
Received: b'\xff'
Received: b'\x00'
Received: b'\x17'
Received: b'\x03'
Received: b'\x01'
Received: b'\x02'
Received: b'\x00'
Received: b'\x10'
Connection closed or reset
请注意，这是正确的错误消息长度通知。
这是错误消息的 Wireshark 解码：
这是通知的 Wireshark 解码：
如果测试程序在未尝试读取通知消息的情况下终止，则被测 BGP 扬声器将无法在线路上发送通知消息。这是因为它会在能够发送 NOTIFICATION 之前收到 TCP RST 消息。这很可能就是您没有看到网络上的通知的原因。
的确，我能够通过如下修改测试程序来重现这个假设：
#!/usr/bin/env python3
import socket
import struct
BGP_IP = '172.31.31.121'
SHORT_MSG = (b'\xff\xff\xff\xff\xff\xff\xff\xff' # First 8 bytes of marker
b'\xff\xff\xff\xff\xff\xff\xff\xff' # Last 8 bytes of marker
b'\x00\x10' # Length 16
b'\x01') # Open
def main():
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
print("Socket created")
sock.connect((BGP_IP, 179))
print("Socket connected")
sock.send(SHORT_MSG)
# Trick TCP into sending a RST when the socket is closed
on_off = 1
linger = 0
sock.setsockopt(socket.SOL_SOCKET, socket.SO_LINGER, struct.pack('ii', on_off, linger))
print("Socket linger time set to 0")
# Close the socket
sock.close()
print("Socket closed")
# Terminate without reading the response NOTIFICATION
if __name__ == "__main__":
main()
使用此测试程序，Wireshark 跟踪中缺少通知（与您报告的完全一样）：
请注意，我不得不跳过一些步骤（特别是将延迟时间设置为零）以强制测试程序发送 RST 而不是 FIN ACK。 （有关详细信息，请参阅 Sending a reset in TCP/IP Socket connection。）
如果测试程序发送的是 FIN ACK 而不是 RST（如果您优雅地关闭套接字，甚至在不关闭套接字的情况下正常终止，就会发生这种情况），那么被测 BGP 扬声器将能够发送 NOTIFICATION在收到 FIN ACK 之后但在发送自己的 FIN ACK 之前。
我正在 ubuntu 上使用 bgp 实现。我想在 bgp 数据包中做一些畸形，bgp 将我们的大小限制在 19 到 4096 之间，但是为了测试目的，我将大小更改为小于 19 和大于 4096。之后，当我将这个数据包从一秒发送到秒时，在两个发言者之间建立了 bgp 会话，第二个应该发送包含错误的通知消息：消息长度错误。 但我没有得到它，而是它在 wireshark 中显示格式错误的数据包，而且我无法在 wireshark 中打开该数据包。任何人都可以帮助我处理这种数据包畸形并获得通知错误。
仅供参考：我已经尝试了所有数据包，如打开、更新和保持活动。格式错误的打开数据包：
下面的更新答案
Wireshark 中显示的 BGP 数据包具有标记字段 (16 x ff)，后跟长度 16 (00 10)。
因此，这确实是您想要测试的场景：您的测试 BGP 扬声器发送了一个长度不正确的 BGP 数据包，而被测远程 BGP 扬声器应该通过发回带有错误代码的通知数据包来响应 "Message Header Error" 和错误 sub-code "Bad Message Length".
Wireshark 显示从测试仪 BGP 扬声器发送到被测 BGP 扬声器的格式错误的 BGP 数据包。 Wireshark 抱怨它是格式错误的 BGP 数据包是正确的：格式错误是因为长度无效。显然，Wireshark 并没有特别说明它不喜欢数据包的哪些方面。
您应该查看反向的 TCP 流（源 10.0.0.2 目标 10.0.0.1）并查找被测 BGP 发言者发回的 BGP NOTIFICATION 数据包。
更新的答案从这里开始
根据错误消息 ([Error] bgp_read_packet error: Connection reset)，您似乎正在测试 Free Range Routing，或者它的前身之一 Quagga 或 Zebra。
我重现了您正在测试的场景。
我是 运行 具有以下配置的自由范围路由 (FRR) BGP 发言人：
Current configuration:
!
frr version 7.1-dev-MyOwnFRRVersion
frr defaults traditional
hostname ip-172-31-31-121
log file /var/log/frr/debug.log
log syslog
service integrated-vtysh-config
!
debug bgp neighbor-events
!
router bgp 100
neighbor X.X.X.X remote-as 200
!
line vty
!
end
我使用下面的 Python 测试程序发送带有 "too short" header 的消息：
#!/usr/bin/env python3
import socket
BGP_IP = 'Y.Y.Y.Y'
SHORT_MSG = (b'\xff\xff\xff\xff\xff\xff\xff\xff' # First 8 bytes of marker
b'\xff\xff\xff\xff\xff\xff\xff\xff' # Last 8 bytes of marker
b'\x00\x10' # Length 16
b'\x01') # Open
def main():
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
print("Socket created")
sock.connect((BGP_IP, 179))
print("Socket connected")
sock.send(SHORT_MSG)
print("Short message sent")
while True:
data = sock.recv(1)
if data == b'':
print("Connection closed or reset")
break
print("Received:", data)
if __name__ == "__main__":
main()
将X.X.X.X替换为测试仪的IP地址，将Y.Y.Y.Y替换为被测BGP扬声器的IP地址。
在这种情况下，被测 BGP 扬声器确实发送了正确的 NOTIFICATION 消息。
这是 FRR 日志报告的内容：
2019/02/09 21:49:05 BGP: 172.31.17.121 [FSM] Timer (connect timer expire)
2019/02/09 21:49:05 BGP: 172.31.17.121 [FSM] ConnectRetry_timer_expired (Active->Connect), fd -1
2019/02/09 21:49:05 BGP: 172.31.17.121 [Event] Connect start to 172.31.17.121 fd 26
2019/02/09 21:49:05 BGP: 172.31.17.121 [FSM] Non blocking connect waiting result, fd 26
2019/02/09 21:49:05 BGP: bgp_fsm_change_status : vrf 0, established_peers 0
2019/02/09 21:49:05 BGP: 172.31.17.121 went from Active to Connect
2019/02/09 21:49:05 BGP: 172.31.17.121 [Event] Connect failed 111(Connection refused)
2019/02/09 21:49:05 BGP: 172.31.17.121 [FSM] TCP_connection_open_failed (Connect->Active), fd 26
2019/02/09 21:49:05 BGP: bgp_fsm_change_status : vrf 0, established_peers 0
2019/02/09 21:49:05 BGP: 172.31.17.121 went from Connect to Active
2019/02/09 21:49:08 BGP: [Event] BGP connection from host 172.31.17.121 fd 26
2019/02/09 21:49:08 BGP: bgp_fsm_change_status : vrf 0, established_peers 0
2019/02/09 21:49:08 BGP: 172.31.17.121 went from Idle to Active
2019/02/09 21:49:08 BGP: 172.31.17.121 [FSM] TCP_connection_open (Active->OpenSent), fd 26
2019/02/09 21:49:08 BGP: 172.31.17.121 passive open
2019/02/09 21:49:08 BGP: 172.31.17.121 Sending hostname cap with hn = ip-172-31-31-121, dn = (null)
2019/02/09 21:49:08 BGP: 172.31.17.121 sending OPEN, version 4, my as 100, holdtime 180, id 172.31.31.121
2019/02/09 21:49:08 BGP: bgp_fsm_change_status : vrf 0, established_peers 0
2019/02/09 21:49:08 BGP: 172.31.17.121 went from Active to OpenSent
2019/02/09 21:49:08 BGP: 172.31.17.121 bad message length - 16 for OPEN
2019/02/09 21:49:08 BGP: %NOTIFICATION: sent to neighbor 172.31.17.121 1/2 (Message Header Error/Bad Message Length) 2 bytes 00 10
2019/02/09 21:49:08 BGP: 172.31.17.121 [FSM] BGP_Stop (OpenSent->Idle), fd 26
2019/02/09 21:49:08 BGP: bgp_fsm_change_status : vrf 0, established_peers 0
2019/02/09 21:49:08 BGP: 172.31.17.121 went from OpenSent to Deleted
注意 "Bad Message Length" 消息。
测试程序报告如下：
Socket created
Socket connected
Short message sent
Received: b'\xff'
Received: b'\xff'
Received: b'\xff'
Received: b'\xff'
Received: b'\xff'
Received: b'\xff'
Received: b'\xff'
Received: b'\xff'
Received: b'\xff'
Received: b'\xff'
Received: b'\xff'
Received: b'\xff'
Received: b'\xff'
Received: b'\xff'
Received: b'\xff'
Received: b'\xff'
Received: b'\x00'
Received: b'\x17'
Received: b'\x03'
Received: b'\x01'
Received: b'\x02'
Received: b'\x00'
Received: b'\x10'
Connection closed or reset
请注意，这是正确的错误消息长度通知。
这是错误消息的 Wireshark 解码：
这是通知的 Wireshark 解码：
如果测试程序在未尝试读取通知消息的情况下终止，则被测 BGP 扬声器将无法在线路上发送通知消息。这是因为它会在能够发送 NOTIFICATION 之前收到 TCP RST 消息。这很可能就是您没有看到网络上的通知的原因。
的确，我能够通过如下修改测试程序来重现这个假设：
#!/usr/bin/env python3
import socket
import struct
BGP_IP = '172.31.31.121'
SHORT_MSG = (b'\xff\xff\xff\xff\xff\xff\xff\xff' # First 8 bytes of marker
b'\xff\xff\xff\xff\xff\xff\xff\xff' # Last 8 bytes of marker
b'\x00\x10' # Length 16
b'\x01') # Open
def main():
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
print("Socket created")
sock.connect((BGP_IP, 179))
print("Socket connected")
sock.send(SHORT_MSG)
# Trick TCP into sending a RST when the socket is closed
on_off = 1
linger = 0
sock.setsockopt(socket.SOL_SOCKET, socket.SO_LINGER, struct.pack('ii', on_off, linger))
print("Socket linger time set to 0")
# Close the socket
sock.close()
print("Socket closed")
# Terminate without reading the response NOTIFICATION
if __name__ == "__main__":
main()
使用此测试程序，Wireshark 跟踪中缺少通知（与您报告的完全一样）：
请注意，我不得不跳过一些步骤（特别是将延迟时间设置为零）以强制测试程序发送 RST 而不是 FIN ACK。 （有关详细信息，请参阅 Sending a reset in TCP/IP Socket connection。）
如果测试程序发送的是 FIN ACK 而不是 RST（如果您优雅地关闭套接字，甚至在不关闭套接字的情况下正常终止，就会发生这种情况），那么被测 BGP 扬声器将能够发送 NOTIFICATION在收到 FIN ACK 之后但在发送自己的 FIN ACK 之前。