首页 > 解决方案 > 将 BGP 数据包大小更改为小于 19 且大于 4096

问题描述

我正在使用 ubuntu 上的 bgp 实现。我想在 bgp 数据包中做一些畸形,bgp 将我们的大小限制在 19 到 4096 之间,但是出于测试目的,我将大小更改为小于 19 和大于 4096。之后,当我将这个数据包从一秒发送到一秒时,在两个发言者之间建立了 bgp 会话,第二个应该发送包含错误的通知消息:消息长度错误。但是我没有得到它,而是在wireshark中显示格式错误的数据包,而且我无法在wireshark中打开该数据包。任何人都可以帮助我解决这种数据包畸形并获得通知错误。

仅供参考:我已经尝试了每个数据包,例如 open、update 和 keepalive。格式错误的开放数据包:

标签: scapybgp

解决方案


更新的答案如下

Wireshark 中显示的 BGP 数据包具有标记字段 (16 x ff),后跟长度 16 (00 10)。

因此,这确实是您想要测试的场景:您的测试 BGP 扬声器发送了一个长度不正确的 BGP 数据包,并且正在测试的远程 BGP 扬声器应该通过发送回一个带有错误代码“消息头错误”的 NOTIFICATION 数据包和错误子代码“错误消息长度”。

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),您似乎正在测试自由范围路由,或其前身 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 测试程序发送带有“太短”标头的消息:

#!/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

请注意“错误消息长度”消息。

以下是测试程序报告的内容:

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 解码:

在此处输入图像描述

如果测试程序在没有尝试读取 NOTIFICATION 消息的情况下终止,则被测 BGP 扬声器将无法在线发送 NOTIFICATION 消息。这是因为它将在能够发送 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 跟踪中缺少 NOTIFICATION(正如您报告的那样):

在此处输入图像描述

请注意,我必须跳过一些障碍(特别是将逗留时间设置为零)以强制测试程序发送 RST 而不是 FIN ACK。(有关详细信息,请参阅在 TCP/IP 套接字连接中发送重置。)

如果测试程序发送的是 FIN ACK 而不是 RST(如果您优雅地关闭套接字,甚至正常终止而不关闭套接字,就会发生这种情况),那么被测 BGP 扬声器将能够在收到 FIN ACK 后发送 NOTIFICATION但在发送自己的 FIN ACK 之前。


推荐阅读