Изменение размера пакета BGP меньше 19 и больше 4096 - PullRequest
Новая
       60

Изменение размера пакета BGP меньше 19 и больше 4096

0 голосов
/ 30 января 2019

Я работаю с реализацией bgp в Ubuntu.Я хочу сделать некоторые ошибки в пакетах bgp, bgp ограничивает нас размером от 19 до 4096, однако для целей тестирования я изменяю размер меньше 19 и больше 4096. После этого, когда я отправляю этот пакет от одной до второй, включаюустановлен сеанс bgp между двумя ораторами, второй должен отправить уведомление с ошибкой: неверная длина сообщения.Но я не понимаю, что он показывает неверно сформированный пакет в Wireshark, а также я не могу открыть этот пакет в Wireshark.Может ли кто-нибудь помочь мне в этом сбое пакета и получить сообщение об ошибке.

Просто для информации: я пробовал все пакеты, такие как открытие, обновление и keepalive.неправильно сформированный открытый пакет:

1 Ответ

0 голосов
/ 30 января 2019

ОБНОВЛЕННЫЙ ОТВЕТ НИЖЕ

Пакет BGP, показанный в Wireshark, имеет поле маркера (16 x ff), за которым следует длина 16 (00 10).

Таким образом, этоэто действительно тот сценарий, который вы хотели протестировать: ваш BGP-динамик тестера отправил пакет BGP с неверной длиной, а тестируемый удаленный BGP-динамик должен ответить, отправив обратно пакет NOTIFICATION с кодом ошибки «Ошибка заголовка сообщения» и вложенной ошибкой.код "Bad Message Length".

Wireshark показывает искаженный пакет BGP, который был отправлен из динамика BGP тестера в тестируемый динамик BGP.Wireshark правильно утверждает, что это неверно сформированный пакет BGP: он искажен из-за неправильной длины.Очевидно, что Wireshark не очень конкретен в отношении того, что ему не нравится в пакете.

Вы должны посмотреть в потоке TCP в обратном направлении (источник 10.0.0.2, назначение 10.0.0.1) и искать BGP.Пакет УВЕДОМЛЕНИЯ, который отправил тестируемый динамик BGP.

ОБНОВЛЕННЫЙ ОТВЕТ НАЧИНАЕТСЯ ЗДЕСЬ

На основании сообщения об ошибке ([Error] bgp_read_packet error: Connection reset) похоже, что вы тестируетеFree Range Routing или один из его предшественников Quagga или Zebra.

Я воспроизвел сценарий, который вы тестируете.

Я использую BGP-динамик Free Range Routing (FRR) со следующей конфигурацией:

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 на IP-адрес тестируемого динамика BGP.

В этом случае тестируемый динамик BGP действительно отправляет правильное сообщение NOTIFICATION.

Вот wесли отчеты журнала 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 для плохого сообщения:

enter image description here

Вот декодер WiresharkУВЕДОМЛЕНИЯ:

enter image description here

Если тестовая программа завершается без попытки прочитать сообщение УВЕДОМЛЕНИЕ, то тестируемый динамик BGP не сможет отправитьсообщение УВЕДОМЛЕНИЯ на проводе.Это связано с тем, что он получит сообщение 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 отсутствует УВЕДОМЛЕНИЕ (именно так, как вы о нем сообщили):

enter image description here

Обратите внимание, что мне пришлось перепрыгивать через некоторые обручи (в частности,установка времени задержки на ноль), чтобы заставить тестовую программу отправлять RST, а не FIN ACK.(Подробнее см. Отправка сброса в сокет TCP / IP .)

Если тестовая программа отправляет FIN ACK вместо RST (что происходит, если вы аккуратно закрываете сокет, илидаже обычно завершается без закрытия сокета), тогда тестируемый динамик BGP сможет отправить УВЕДОМЛЕНИЕ после получения FIN ACK, но перед отправкой своего собственного FIN ACK.

...