Односпрямована втрата пакетів


8

Нещодавно після оновлення декількох схем MetroE (підключення L2) від 100 Мбіт до 1 Гбіт / с я помітив, що великі передачі файлів провалюються між деякими сайтами; однак передача провалюється лише в напрямку. Наприклад, розглянемо наступний приклад.

Від -> До

A -> B = провал

B -> A = Успіх

A -> C = успіх

C -> A = Успіх

B -> C = успіх

C -> B = успіх

Кожен сайт є маршрутизованим сегментом позаду комутатора L3, розташованого на сайті. Перемикач L3 підключається до медіаконвертера CPE провайдера, який, в свою чергу, підключається до мережі постачальника через волокно. Статична маршрутизація використовується між перемикачами L3.

            *Site A*                      *Site B*
    L3 Switch <-> CPE <--- Provider ---> CPE <-> L3 Switch
                               |
                              CPE
                               |
                           L3 Switch
                            *Site C*

Постачальник провів тестування ланцюгів від CPE до кінця і не повідомив про втрати. Однак я бачу багато повторюваних ACK-файлів у захопленні пакетів на хостах, перш ніж передача не вдасться.

Якщо я видаляю вимикачі L3 з рівняння і підключаю два хости безпосередньо до пристрою CPE на кожному сайті, передача файлів завершується успішно.

    Host A <-> CPE <--- Provider ---> CPE <-> Host B

Якщо я розміщую хости з обох боків перемикача L3, маршрутизація між VLAN працює без перешкод і передача файлів успішно завершується.

    Host A1 <-> L3 Switch <-> Host A2

Здається, проблема виникає лише тоді, коли дані проходять постачальника між двома маршрутизованими сегментами.

    Host A <-> L3 Switch <-> CPE <--- Provider ---> CPE <-> L3 Switch <-> Host B

Я перевірив ряд речей - статистика інтерфейсу чиста (без помилок), низьке використання процесора та пам'яті, відповідність швидкості та дуплексу (клієнт та CPE), таблиці MAC та ARP правильні та ін.

Що може бути проблемою?

Оновлення 1

Захоплення пакетів від хостів A і B можна знайти за такою URL-адресою:

https://www.dropbox.com/sh/5m2yohgxieelo59/AADed-0EWOkdmFIe0qT45_uQa

Первісна проблема виникла за допомогою перемикачів Juniper EX3200 під керуванням 12.3R6.6. Згодом я знизив перемикачі до 11.4R6.6, але це не вирішило проблему.

Мені вдалося повторити проблему за допомогою перемикачів Juiper EX2200 під керуванням 12.3R6.6 та 11.4R6.6. Я також зміг повторити проблему за допомогою перемикачів Dell 6224, що працюють 3.3.11.2.

В даний час до ялівцю EX3200 підключено лише CPE (ge-0/0/0) і один хост (ge-0/0/1) на кожному майданчику. Під час усунення проблеми я викреслив конфігурацію будь-яких сторонніх параметрів, тому конфігурація є досить базовою. Конфігурація по суті однакова у кожного, але з різними IP-адресами. Нижче - фрагмент.

    # show interfaces
    ge-0/0/0 {
        unit 0 {
            family ethernet-switching {
                port-mode access;
                vlan {
                    members WAN;
                }
            }
        }
    }
    ge-0/0/1 {
        unit 0 {
            family ethernet-switching {
                port-mode access;
                vlan {
                    members LAN;
                }
            }
        }
    }
    vlan {
        unit 10 {
            description WAN;
            family inet {
                address 192.168.X.X/27;
            }
        }
        unit 100 {
            description LAN;
            family inet {
                targeted-broadcast;
                address 172.X.X.1/22;
            }
        }
    }

    # show vlans
    WAN {
        vlan-id 10;
        l3-interface vlan.10;
    }
    LAN {
        vlan-id 100;
        l3-interface vlan.100;
    }

Оновлення 2

Сьогодні я помітив, що якщо я сканую файл з комутатора L3, Juniper EX3200, на сайті A до L3 комутатора, Juniper EX3200, на сайті B, на передачу scp також вплине проблема.

Я вважаю це особливо цікавим, оскільки передача відбувається від інтерфейсу CPE, що знаходиться в мережі WAN VLAN, тому що якщо я з'єднаю VLAN між ураженими сайтами через комутатори EX3200, передача комутованих файлів успішно завершується між хостами на сайтах A і B.


1
Привіт Майку, дякую за пропозицію. Я знаю з розмови з моїм провайдером, що вони налаштовують MTU понад 9000. Я в змозі пропустити 1472 байти в обох напрямках, що я б очікував від дефакто 1500 MTU. Використання mturoute підтвердило це. Будь-який пінг понад 1472 не вдається встановити біт "фрагмент".
Пол Гарретт

Будь ласка, нюхайте передачу файлів, яка не вдається з обох сторін одночасно, та опублікуйте результати на Cloudhark. Нам також потрібні деталі щодо частини питання "комутатор L3". Такі речі, як виробник, модель, версія вбудованого ПЗ, конфігурація, номери портів, підключені до тощо ...
Майк Пеннінгтон,

На той момент, коли передача файлів не вдалася, захоплення склало близько 19 Мб, що занадто велико для краудшерку, тому я завантажив зйомки в папку і поділився посиланням. Я оновив публікацію, щоб включити додаткову інформацію, яку ви запитували.
Пол Гарретт

Будь ласка, подумайте про те, щоб додати більше детальних запитань
Майк Пеннінгтон,

Виникла проблема з мережею провайдера. Додаткових відомостей не було.
Пол Гарретт

Відповіді:


1

На брандмауері, якщо ви використовуєте SRX, перевірте, для чого встановлено ваш сеанс потоку безпеки та чи досягає він межі.

#show security flow session summary 
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.