Bit error rate too high

Introduction

This document describes the reasons why a Fibre Channel (FC) port on a Multilayer Director Switch (MDS) or Nexus FC capable switch is brought down due to «Error disabled — bit error rate too high».

A detailed description of Error Disabled states can be found here:

Troubleshooting FC Ports

Verify

Step 1. Use the show interface command to verify that the switch detected a problem and disabled the port.

Step 2. Use the show interface fcX/Y transceiver detail command to view information about the signal levels on the Small Form-Factor Pluggable (SFP) transceiver.

If the port is currently down, you may have to bring it up first:

switch# config ; interface fc3/1 ; no shut ; sh interface fc3/1 transceiver detail
fc3/1 sfp is present
    Name is CISCO-AVAGO
    Manufacturer's part number is SFBR-5780APZ-CS2
    Revision is G2.3
    Serial number is AGD16348ETR
    Cisco part number is 10-2418-01
    Cisco pid is DS-SFP-FC8G-SW
    FC Transmitter type is short wave laser w/o OFC (SN)
    FC Transmitter supports short distance link length
    Transmission medium is multimode laser with 62.5 um aperture (M6)
    Supported speeds are - Min speed: 2000 Mb/s, Max speed: 8000 Mb/s
    Nominal bit rate is 8500 Mb/s
    Link length supported for 50/125um OM2 fiber is 50 m
    Link length supported for 62.5/125um fiber is 21 m
    Link length supported for 50/125um OM3 fiber is 150 m
    Cisco extended id is unknown (0x0)

    No tx fault, no rx loss, in sync state, diagnostic monitoring type is 0x68
    SFP Diagnostics Information:
----------------------------------------------------------------------------
                                     Alarms                  Warnings
                                High        Low         High          Low
----------------------------------------------------------------------------
  Temperature  27.73 C         75.00 C     -5.00 C     70.00 C        0.00 C
  Voltage       3.30 V          3.63 V      2.97 V      3.46 V        3.13 V
  Current       6.14 mA        10.50 mA     2.00 mA    10.50 mA       2.00 mA
  Tx Power     -2.52 dBm        1.70 dBm  -14.00 dBm   -1.30 dBm    -10.00 dBm
  Rx Power     -2.81 dBm        3.00 dBm  -17.30 dBm    0.00 dBm    -13.30 dBm
  Transmit Fault Count = 0
----------------------------------------------------------------------------
  Note: ++  high-alarm; +  high-warning; --  low-alarm; -  low-warning

switch#

Above indicates signal levels are within specification.

Troubleshoot

A description of Error Disabled states can be found here:

Bit Error Threshold

Bit Error Thresholds

• Faulty or bad cable.
• Faulty or bad GBIC or SFP.
• GBIC or SFP is specified to operate at 1 Gbps but is used at 2 Gbps.
• GBIC or SFP is specified to operate at 2 Gbps but is used at 4 Gbps.
• Short haul cable is used for long haul or long haul cable is used for short haul.
• Momentary sync loss.
• Loose cable connection at one or both ends.
• Improper GBIC or SFP connection at one or both ends.

A BER threshold is detected when 15 error bursts occur in a 5-minute period. By default, the switch disables the interface when the threshold is reached. Use the shutdown and no shutdown command sequence to re-enable the interface.

Rule out faulty physical equipment by replacing cable/s, GBICs/SFPs and also by pass patch-panel a step at a time.

You can configure the switch to not disable an interface when the threshold is crossed. By default, the threshold disables the interface.

no switchport ignore bit-errors

Note: It is not advisable to leave above setting on indefinitely, rather to be used during troubleshooting sessions.

Note: Regardless of the setting of the switchport ignore bit-errors command, a switch generates a syslog message when the BER threshold is exceeded.

The creditmon process also monitors bit errors.

show process creditmon credit-loss-event-history

For the N5K and N6K, the command is

show platform software fcpc event-history errors
Event:E_DEBUG, length:102, at 571407 usecs after Tue Jan  5 05:33:02 2016 
    [102] CREDITMON_EVENT_ERR_COUNT, if_index 1105000: cur=0x2acfd01e76de prev=0x2acfd01e76dd ocurances=3

Once the problem hardware has been identified and addressed, a no shutdown of the interface may be required to bring the port up and the bit errors should not be seen thereafter.

Caveats

Be aware of these 2 defects that disables the port/s when 15 bursts of bit errors occur within 5 hours instead of 5 minutes.

It’s still a physical layer issue and needs to be addressed.

FC interface disabled due to ‘bit error rate too high’ when rate is low

Nexus: Cisco BugID CSCux76712

MDS: Cisco BugID CSCuo56792

Tech Note on FC Port Down due to «Error disabled — bit error rate too high»

Available Languages

Download Options

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Contents

Introduction

This document describes the reasons why a Fibre Channel (FC) port on a Multilayer Director Switch (MDS) or Nexus FC capable switch is brought down due to «Error disabled — bit error rate too high».

A detailed description of Error Disabled states can be found here:

Verify

Step 1. Use the show interface command to verify that the switch detected a problem and disabled the port.

Verify the ErrDisable State Using the CLI:

show interface

fc3/1 is down (Error disabled — bit error rate too high)

Step 2. Use the show interface fcX/Y transceiver detail command to view information about the signal levels on the Small Form-Factor Pluggable (SFP) transceiver.

If the port is currently down, you may have to bring it up first:

Above indicates signal levels are within specification.

Troubleshoot

A description of Error Disabled states can be found here:

Bit Error Thresholds

The Bit Error Rate (BER) threshold is used by a switch to detect an increased error rate before performance degradation seriously affects traffic.

Bit errors occur because of these reasons:

• Faulty or bad cable.
• Faulty or bad GBIC or SFP.
• GBIC or SFP is specified to operate at 1 Gbps but is used at 2 Gbps.
• GBIC or SFP is specified to operate at 2 Gbps but is used at 4 Gbps.
• Short haul cable is used for long haul or long haul cable is used for short haul.
• Momentary sync loss.
• Loose cable connection at one or both ends.
• Improper GBIC or SFP connection at one or both ends.

A BER threshold is detected when 15 error bursts occur in a 5-minute period. By default, the switch disables the interface when the threshold is reached. Use the shutdown and no shutdown command sequence to re-enable the interface.

Rule out faulty physical equipment by replacing cable/s, GBICs/SFPs and also by pass patch-panel a step at a time.

You can configure the switch to not disable an interface when the threshold is crossed. By default, the threshold disables the interface.

no switchport ignore bit-errors

Note: It is not advisable to leave above setting on indefinitely, rather to be used during troubleshooting sessions.

Note: Regardless of the setting of the switchport ignore bit-errors command, a switch generates a syslog message when the BER threshold is exceeded.

The creditmon process also monitors bit errors.

For the N5K and N6K, the command is

Once the problem hardware has been identified and addressed, a no shutdown of the interface may be required to bring the port up and the bit errors should not be seen thereafter.

Caveats

Be aware of these 2 defects that disables the port/s when 15 bursts of bit errors occur within 5 hours instead of 5 minutes.

It’s still a physical layer issue and needs to be addressed.

FC interface disabled due to ‘bit error rate too high’ when rate is low

Источник

Troubleshooting Bit Error Rate Errors on SONET Links

Available Languages

Download Options

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Contents

Introduction

This document explains bit interleaved parity (BIP-8) checks on frames that a packet over SONET (POS) router interface transmits.

Prerequisites

Requirements

Cisco recommends that you have knowledge of these topics:

SONET (Synchronous Optical NETwork).

GSR (Gigabit Switch Router).

ESR (Edge Services Router).

Components Used

This document is not restricted to specific software and hardware versions.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Background Information

When the number of BIP errors crosses a threshold that you can configure, the router reports log messages similar to this:

This document provides tips on how to troubleshoot threshold-crossing (TC) bit error rate (BER) alarms.

BIP-8 Bytes in SONET Overhead

SONET is a protocol that uses an architecture of layers: section, line and path. Each layer adds some number of overhead bytes to the SONET frame, as illustrated here:

Importantly, each layer uses a single, interleaved parity byte to provide error monitoring across a particular segment, along the end-to-end SONET path. This parity byte is known as BIP-8, which is an abbreviation for bit interleaved parity. BIP-8 performs an even-parity check on the previous Synchronous Transport Signal level 1 (STS-1) frame.

During the parity check, the first bit of the BIP-8 field is set so that the total number of ones in the first bit of all octets of the previously scrambled STS-1 frame is an even number. The second bit of the BIP-8 field is used exactly the same way, except that this bit performs a check on the second bits of each octet, and so on.

The Bellcore GR-253 standard for SONET networks defines the bytes over which a particular parity error is calculated. This table describes the portion of the SONET frame that a particular BIP byte covers:

When Do Particular BIP Errors Occur?

Under some conditions, the output of the show controllers pos command reports only one level of BIP errors. The reason is that the reported BIP errors vary depending on where the code violation or bit flip actually occurs. In other words, parity bytes monitor and detect errors over different parts of a SONET frame. A BIP error can occur anywhere in the frame.

This diagram illustrates a typical SONET network:

When you connect two router POS interfaces point to point, over a dense wavelength division multiplexing (DWDM) link without intermediate SONET or Synchronous Digital Hierarchy (SDH) equipment, all three BIP mechanisms monitor the same segment, and typically detect the same errors. However, in this configuration, B2 must provide the most accurate bit error count.

An increment in B1 and B2 errors, without an increment in B3 errors is statistically improbable. This condition occurs only if the errors affect parts of the frame that the B3 byte does not monitor. Recall that the B3 byte covers the path overhead and payload section.

An increment in B3 errors points to a corrupt SPE or payload portion. The path overhead does not change until a remote PTE terminates the SONET frame. ADMs and regenerators do not terminate the path overhead and must not report B3 errors. Thus, a condition in which B3 errors increase only indicates that either the local or remote router interface corrupts the path overhead or payload.

In addition, when the B3 check covers the longest span, the chance of bit flips is greater. Typically, the end-to-end path spans a few monitored segments between LTEs. The B2 parity check must monitor these segments.

SONET interfaces must not report an increase in BIP errors during a loss of signal or loss of frame alarm condition. However, a burst of B1 errors can occur during the time the interface takes to declare the alarm. This burst can last for up to 10 seconds, which is the interval at which the line cards in the Cisco 12000 and 7500 router series report statistics to the central route processor.

In addition, you must understand that BIP errors have different error detection resolutions, which are explained here:

B1: B1 can detect up to eight parity errors per frame. This level of resolution is not acceptable at OC-192 rates. Even-numbered errors can elude the parity check on links with high error rates.

B2: B2 can detect a far higher number of errors per frame. The exact number increases as the number of STS-1s (or STM-1s) increases in the SONET frame. For example, an OC-192/STM-64 produces a 192 x 8 = 1536 bit-wide BIP field. In other words, B2 can count up to 1536 bit errors per frame. There is considerably less chance of an even-numbered error that eludes the B2 parity calculation. B2 offers superior resolution when compared to B1 or B3. Therefore, a SONET interface can report B2 errors only for a particular monitored segment.

B3: B3 can detect up to eight parity errors in the entire SPE. This number produces acceptable resolution for a channelized interface because, (for example) each STS-1 in an STS-3 has a path overhead and B3 byte. However, this number produces poor resolution over concatenated payloads in which a single set of path overhead must cover a relatively large payload frame.

Note: When you initiate an IOS reload or a microcode reload, the POS interface is reset, and so is the framer. The reset downloads the microcode on the interface again. In some cases, this process can generate a small burst of bit errors.

The BER counts the number of detected BIP errors. In order to calculate this value, compare the number of bit errors to the total number of bits transmitted per unit of time.

Set BER Thresholds

POS interfaces use the BER to determine whether a link is reliable. The interface changes the state to down if the BER exceeds a threshold that you can configure.

All three SONET layers use a default BER value of 10e-6. The show controllers pos command displays the current values.

Use the pos threshold command to adjust the threshold values from the defaults.

Signal failure (SF) BER and signal degrade (SD) BER are sourced from B2 BIP-8 error counts (as is B2-TCA). However, SF-BER and SD-BER feed into the automatic protection switching (APS) machine, and can lead to a protection switch (if you have configured APS).

B1 BER Threshold Crossing Alert (B1-TCA), B2-TCA, and B3-TCA only print a log message to the console if you have enabled reports for them.

Report BIP Errors

This sample output shows how a POS interface on a Cisco router reports a high BER.

How Does a Router Respond to BIP Errors?

When a Cisco POS interface detects a BIP error, the interface does not discard the frame. The reason is that the BIP value carried in the current frame is the value calculated on the previous frame. In order to calculate the BIP value on the entire frame, the entire frame needs to be created. At SONET speeds, a frame is quite large and would occupy a large amount of buffer resources. The actual approach is to avoid any delay in sending the frame that normally occurs until the parity calculation. This approach minimizes buffer requirements. Parity calculation occurs after the actual transmission of the frame.

For example, the parity value for frame 100 is placed in the BIP field of frame 101.

As long as the SONET framer can maintain frame alignment, the frame is sent to the layer-2 protocol. If the layer-2 data within the frame is corrupt, the frame is dropped as a cyclic redundancy check (CRC).

Steps to Troubleshoot

Use these steps to troubleshoot the SONET alarms and defects that this document describes:

Check the optical power levels. Ensure that the link has sufficient attenuation.

Ensure that bad or dirty fiber does not cause the bit errors. Complete these steps:

Clean the physical fiber and the interfaces.

Swap the cables.

Check any patch panels.

Ensure proper clock settings.

Draw out the topology, and check for any transport devices or signal regenerators in between the two ends. Check and clean these devices also.

Perform hard loopback tests. Loop a single strand of fiber into the transmit and receive connectors of the interface. Then ping the IP address of the interface to ensure that the interface is capable of actual data flow. For more information, refer to Understanding Loopback Modes on Cisco Routers.

When you contact the Cisco Technical Assistance Center (TAC):

Collect output from the show running-config command.

Collect output from the show controllers pos details command. Determine the number of SONET-level bit errors.

Wait a few minutes.

Capture the output of show controllers pos details command again for the same interface.

Here is a table that appears in the Cisco 10000 Series ESR Troubleshooting Guide. This table provides the steps to troubleshoot BIP TC alarms.

Note: A known issue with Gigabit Switch Router (GSR) POS cards is that a hard loop results in ping loss because the GSR rate-limits packets are pushed to the Gigabit Route Processor (GRP). For more information, refer to Cisco bug ID CSCea11267 (registered customers only) .

Bit Errors on ATM Interfaces

Campus ATM switches, for example, the LightStream 1010 and Catalyst 8500, do not support a command to configure the TC alarm value on ATM over SONET interfaces.

Troubleshoot TC alarms on ATM switches with the same steps as on POS interfaces. Bit errors point to a physical layer problem between the ATM switch and other devices in the path.

Источник

В цифровой передаче, количество битовых ошибок является количеством принятых бит одного потока данных над каналом связи, которые были изменены из — за шум, помехи, искажений или битой синхронизацию ошибок.

Коэффициент битовых ошибок ( BER ) — это количество битовых ошибок в единицу времени. Коэффициент битовых ошибок (также BER ) — это количество битовых ошибок, деленное на общее количество переданных битов за исследуемый интервал времени. Коэффициент битовых ошибок — это безразмерная мера производительности, часто выражаемая в процентах .

Бита вероятность ошибка р _е является ожидаемым значением коэффициента ошибок по битам. Коэффициент битовых ошибок можно рассматривать как приблизительную оценку вероятности битовых ошибок. Эта оценка точна для длительного интервала времени и большого количества битовых ошибок.

Пример

В качестве примера предположим, что эта переданная битовая последовательность:

0 1 1 0 0 0 1 0 1 1

и следующая полученная битовая последовательность:

0 0 1 0 1 0 1 0 0 1,

Количество битовых ошибок (подчеркнутые биты) в этом случае равно 3. BER — это 3 неверных бита, разделенных на 10 переданных битов, в результате чего BER составляет 0,3 или 30%.

Коэффициент ошибок пакета

Коэффициент ошибок пакетов (PER) — это количество неправильно принятых пакетов данных, деленное на общее количество принятых пакетов. Пакет объявляется некорректным, если хотя бы один бит ошибочен. Ожидаемое значение PER обозначается вероятностью ошибки пакета p _p, которая для длины пакета данных N бит может быть выражена как

,

предполагая, что битовые ошибки не зависят друг от друга. Для малых вероятностей битовых ошибок и больших пакетов данных это примерно

Подобные измерения могут быть выполнены для передачи кадров, блоков или символов .

Факторы, влияющие на BER

В системе связи на BER на стороне приемника могут влиять шум канала передачи, помехи, искажения, проблемы битовой синхронизации, затухание, замирания из-за многолучевого распространения беспроводной связи и т. Д.

BER может быть улучшен путем выбора сильного уровня сигнала (если это не вызывает перекрестных помех и большего количества битовых ошибок), путем выбора медленной и надежной схемы модуляции или схемы линейного кодирования, а также путем применения схем канального кодирования, таких как избыточные коды прямого исправления ошибок. .

КОБ передачи является количество обнаруженных битов, которые являются неправильными до коррекции ошибок, разделенных на общее количество переданных битов ( в том числе избыточных кодов ошибок). Информация КОБ, примерно равна вероятности ошибки декодирования, это число декодированных битов, которые остаются неправильно после коррекции ошибок, деленное на общее число декодированных битов (полезная информация). Обычно BER передачи больше, чем BER информации. На информационный BER влияет сила кода прямого исправления ошибок.

Анализ BER

BER можно оценить с помощью стохастического ( Монте-Карло ) компьютерного моделирования. Если предполагается простая модель канала передачи и модель источника данных, BER также может быть вычислен аналитически. Примером такой модели источника данных является источник Бернулли .

Примеры простых моделей каналов, используемых в теории информации :

• Двоичный симметричный канал (используется при анализе вероятности ошибки декодирования в случае непакетных битовых ошибок в канале передачи)
• Канал аддитивного белого гауссова шума (AWGN) без замирания.

Наихудший сценарий — это полностью случайный канал, в котором шум полностью преобладает над полезным сигналом. Это приводит к BER передачи 50% (при условии, что предполагается источник двоичных данных Бернулли и двоичный симметричный канал, см. Ниже).

В канале с шумом BER часто выражается как функция нормированного показателя отношения несущей к шуму, обозначаемого Eb / N0 (отношение энергии на бит к спектральной плотности мощности шума) или Es / N0 (энергия на символ модуляции для спектральная плотность шума).

Например, в случае QPSK модуляции и канал АБГШ, КОБ в зависимости от Eb / N0 определяется по формуле:
.

Люди обычно строят кривые BER для описания производительности цифровой системы связи. В оптической связи обычно используется зависимость BER (дБ) от принимаемой мощности (дБм); в то время как в беспроводной связи используется BER (дБ) по сравнению с SNR (дБ).

Измерение коэффициента ошибок по битам помогает людям выбрать подходящие коды прямого исправления ошибок. Поскольку большинство таких кодов исправляют только перевороты битов, но не вставки или удаления битов, метрика расстояния Хэмминга является подходящим способом измерения количества битовых ошибок. Многие кодеры FEC также непрерывно измеряют текущий BER.

Более общий способ измерения количества битовых ошибок — это расстояние Левенштейна . Измерение расстояния Левенштейна больше подходит для измерения характеристик сырого канала перед кадровой синхронизацией, а также при использовании кодов коррекции ошибок, предназначенных для исправления вставки и удаления битов, таких как коды маркеров и коды водяных знаков.

Математический проект

BER — это вероятность неправильной интерпретации из-за электрического шума . Рассматривая биполярную передачу NRZ, мы имеем

для «1» и для «0». Каждый из и имеет период .

Зная, что шум имеет двустороннюю спектральную плотность ,

является

и есть .

Возвращаясь к BER, у нас есть вероятность неправильного толкования .

и

где — порог принятия решения, установленный в 0, когда .

Мы можем использовать среднюю энергию сигнала, чтобы найти окончательное выражение:

± §

Проверка коэффициента битовых ошибок

BERT или тест на частоту ошибок по битам — это метод тестирования схем цифровой связи, в котором используются заранее определенные шаблоны нагрузки, состоящие из последовательности логических единиц и нулей, сгенерированных генератором тестовых шаблонов.

BERT обычно состоит из генератора тестовых шаблонов и приемника, который может быть настроен на один и тот же шаблон. Их можно использовать парами, по одному на любом конце линии передачи, или по отдельности на одном конце с кольцевой проверкой на удаленном конце. BERT обычно представляют собой автономные специализированные инструменты, но могут быть основаны на персональном компьютере . При использовании количество ошибок, если таковые имеются, подсчитывается и представляется в виде отношения, например 1 на 1 000 000 или 1 на 1e06.

Распространенные типы стресс-паттернов BERT

• PRBS ( псевдослучайная двоичная последовательность ) — псевдослучайный двоичный секвенсор из N бит. Эти последовательности шаблонов используются для измерения джиттера и глаз-маски TX-данных в электрических и оптических каналах передачи данных.
• QRSS (квазислучайный источник сигнала) — псевдослучайный двоичный секвенсор, который генерирует каждую комбинацию 20-битного слова, повторяет каждые 1048 575 слов и подавляет последовательные нули не более чем до 14. Он содержит последовательности с высокой плотностью, последовательности с низкой плотностью, и последовательности, которые меняются от низкого к высокому и наоборот. Этот шаблон также является стандартным шаблоном, используемым для измерения джиттера.
• 3 из 24 — шаблон содержит самую длинную строку последовательных нулей (15) с самой низкой плотностью (12,5%). Этот шаблон одновременно подчеркивает минимальную плотность единиц и максимальное количество последовательных нулей. Формат кадра D4 3 из 24 может вызвать желтый аварийный сигнал D4 для цепей кадра в зависимости от выравнивания одного бита с кадром.
• 1: 7 — Также упоминается как 1 из 8 . Он имеет только один в восьмибитной повторяющейся последовательности. Этот шаблон подчеркивает минимальную плотность 12,5% и должен использоваться при тестировании средств, установленных для кодирования B8ZS, поскольку шаблон 3 из 24 увеличивается до 29,5% при преобразовании в B8ZS.
• Мин. / Макс. — последовательность быстрого перехода узора с низкой плотности на высокую. Наиболее полезно при усилении функции ALBO ретранслятора .
• Все единицы (или отметка) — шаблон, состоящий только из единиц. Этот шаблон заставляет повторитель потреблять максимальное количество энергии. Если постоянный ток к ретранслятору отрегулирован должным образом, ретранслятор не будет иметь проблем с передачей длинной последовательности. Этот образец следует использовать при измерении регулирования мощности диапазона. Шаблон «все единицы без рамки» используется для обозначения AIS (также известного как синий сигнал тревоги ).
• Все нули — шаблон, состоящий только из нулей. Это эффективно при поиске оборудования, неправильно настроенного для AMI, такого как низкоскоростные входы мультиплексного волокна / радио.
• Чередование нулей и единиц — шаблон, состоящий из чередующихся единиц и нулей.
• 2 из 8 — шаблон содержит не более четырех последовательных нулей. Он не вызовет последовательность B8ZS, потому что для подстановки B8ZS требуется восемь последовательных нулей. Схема эффективна при поиске оборудования, не использованного для B8ZS.
• Bridgetap — разветвления моста в пределах пролета можно обнаружить с помощью ряда тестовых шаблонов с различной плотностью единиц и нулей. Этот тест генерирует 21 тестовую таблицу и длится 15 минут. Если возникает ошибка сигнала, на участке может быть один или несколько ответвлений моста. Этот шаблон эффективен только для участков T1, которые передают необработанный сигнал. Модуляция, используемая в пролетах HDSL, сводит на нет способность шаблонов моста обнаруживать ответвления моста.
• Multipat — этот тест генерирует пять часто используемых тестовых шаблонов, позволяющих проводить тестирование диапазона DS1 без необходимости выбирать каждый тестовый шаблон отдельно. Шаблоны: все единицы, 1: 7, 2 из 8, 3 из 24 и QRSS.
• T1-DALY и 55 OCTET — Каждый из этих шаблонов содержит пятьдесят пять (55) восьмибитовых октетов данных в последовательности, которая быстро изменяется между низкой и высокой плотностью. Эти паттерны используются в основном для нагрузки на схему ALBO и эквалайзера, но они также усиливают восстановление синхронизации. 55 OCTET имеет пятнадцать (15) последовательных нулей и может использоваться только без рамки без нарушения требований к плотности. Для сигналов с фреймами следует использовать шаблон T1-DALY. Оба шаблона вызовут код B8ZS в схемах с опцией для B8ZS.

Тестер коэффициента битовых ошибок

Тестер коэффициента ошибок по битам (BERT), также известный как «тестер коэффициента ошибок по битам» или решение для тестирования коэффициента ошибок по битам (BERT), представляет собой электронное испытательное оборудование, используемое для проверки качества передачи сигнала отдельных компонентов или целых систем.

Основные строительные блоки BERT:

• Генератор шаблонов, который передает определенный тестовый шаблон в ИУ или тестовую систему.
• Детектор ошибок, подключенный к DUT или тестовой системе, для подсчета ошибок, генерируемых DUT или тестовой системой.
• Генератор тактовых сигналов для синхронизации генератора шаблонов и детектора ошибок
• Анализатор цифровой связи не является обязательным для отображения переданного или принятого сигнала.
• Электрооптический преобразователь и оптико-электрический преобразователь для проверки сигналов оптической связи.

Смотрите также

• Пакетная ошибка
• Код исправления ошибок
• Секунда с ошибкой
• Частота ошибок Витерби

использованная литература

 Эта статья включает  материалы, являющиеся общественным достоянием, из документа Управления общих служб : «Федеральный стандарт 1037C» .(в поддержку MIL-STD-188 )

внешние ссылки

• QPSK BER для канала AWGN — онлайн-эксперимент

Error Message 

 PORT-5-IF_DOWN_ADMIN_DOWN: Interface [chars] is down (Administratively down)

[chars] [chars] 

Error Message 

 PORT-5-IF_DOWN_BIT_ERR_RT_THRES_EXCEEDED: Interface [chars] is down (Error

disabled — bit error rate too high) [chars] [chars] 

Error Message 

 PORT-5-IF_DOWN_BUNDLE_MISCFG: Interface [chars] is down (Isolation due to

channel mis-configuration on local or remote switch) [chars] [chars] 

Error Message 

 PORT-5-IF_DOWN_CFG_CHANGE: Interface [chars] is down(Config change) [chars]

[chars] 

Качество сетей передачи данных. Транспорт

В предыдущей статье были затронуты базовые метрики качества сетей и систем передачи данных. Также было обещано написать про то, как все работает изнутри. И намеренно не было упомянуто про качество среды передачи данных и ее характеристиках. Надеюсь, что новая статья даст ответы на эти вопросы.

Среда передачи

Начну, пожалуй, с последнего пункта — качества среды передачи. Как уже написано выше, про нее ничего не говорилось в предыдущем повествовании, поскольку само по себе количество сред и их характеристики очень сильно различаются и зависят от просто колоссального множества факторов. Разбираться во всем этом многообразии задача соответствующих специалистов. Всем очевидно использование радио-эфира в качестве среды передачи данных. Я же помню в конце 90-х начале 00-х особой популярностью у операторов связи стали пользоваться такие экзотические способы передачи, как лазерные атмосферные передатчики. Выглядели они, в зависимости от производителя и конфигурации примерно как на картинке слева (да, почти такой себе светотелефон из радиолюбительского детства). Преимущество их было в том, что не надо было получать разрешение ГРКЧ, да и скорости, по сравнению с радиомостом были несколько больше, кроме того существовали модификации для организации каналов с временным разделением (E1 и т.п.), а подобное оборудование радио-доступа стоило непомерно дорого. Почему не оптический кабель? Потому что в те счастливые времена дикого провайдинга оптика еще была довольно дорогой, а за конвертер интерфейса или активное оборудование, способное принять оптический линк напрямую давали небольшой (а кто-то и большой) брусок золота. Были еще спутниковые каналы, но это вообще из области фантастики и позволить их себе могли разве что компании нефтяного сектора и прочего национального благосостояния. Но работа канала через спутник сводится к использованию радио-эфира, со всеми вытекающими и внесением огромной задержки.

Соответственно погружаясь в вопрос в результате будем иметь множество сред и ни одной обобщенной характеристики. Тем не менее для нас среда это всего лишь транспорт, передающий информацию из точки А в точку Б. А для транспорта (даже общественного) характеристикой отражающей его качество будет доставка всех битов (ну или пассажиров) без искажений и потерь (не хотелось бы лишиться части тела при перевозке, согласитесь). Т.е. мы приходим к такой обобщенной метрике качества транспорта как количество битовых ошибок, или BER (Bit error rate). В чисто пакетных сетях она практически не используется, поскольку ошибки передачи выявляются на уровне пакета, например подсчетом контрольных сумм: FCS (Frame check sequence) для L2 или сhecksum IP для L3. Если контрольная сумма не совпадает, то пакет целиком отбрасывается как невалидный. Если же рассмотреть гетерогенные сети, те в которых транспортом может служить непакетная сеть, а, например, один из вариантов описанных выше, либо вообще используется транзит через ATM, PDH, SDH и подобное без непосредственной (но с восстановлением) передачи пакета, то битовые ошибки транспорта могут значительно влиять, конечно в зависимости от технологии. Рассмотрим инкапсуляцию и передачу Ethernet-фрейма в HDLC. Другие технологии используют практически такую же технику.

Схема читается слева-направо (взята здесь).

1. Какой-то узел сети А отправляет пакет в сторону какого-то узла сети Б
2. Транспорт между сетями построен на сети PDH
3. Узел на границе выхода сети А вырезает из Ethernet-фрейма область полезной нагрузки (поля от DestinationAddress до FCS включительно), оборачивает в HDLC заголовки, и отправляет на граничный узел входа сети Б
4. Граничный узел входа сети Б выделяет область полезной нагрузки и восстанавливает Ethernet-фрейм
5. Фрейм с граничного узла отправляется получателю

Как можно видеть, в данном случае контрольная передается корректно и в случае повреждения битового потока в процессе передачи восстановленный пакет с неверной FCS будет отброшен получателем. В данном случае механизм обнаружения ошибки налицо.

Но не всегда используется надстройка инкапсуляции, либо передается вообще не полноценный фрейм, а лишь поле payload. Т.е. вырезается область, оборачивается во внутренний протокол, а на другой стороне восстанавливаются недостающие данные, включая отсутствующие заголовки L2. Соответственно пропадает и FCS — она просто рассчитывается заново. Таким образом получается, если данные были повреждены, а FCS рассчитан на основании “испорченных” данных, то получатель принимает совсем не тот пакет, который ему отправляли. Это довольно часто встречается в спутниковой связи, чтобы повысить полезную утилизацию канала, избегая передачи условно “лишней” информации. Резюмируя, получается что метрика BER может быть интересна в случаях когда:

• необходимо проверить стабильность физического канала, например для оптики это 10E-12 (упоминается в IEEE802.3)
• Ethernet-фреймы упаковывают в SDH(GFP), PDH, ATM и другие транспортные сети.
• используются технологии xHSL, PPP протоколы в которые упаковывают IP пакеты

BER тест

Метрика известна — это отношение количество битовых ошибок к общему числу переданных битов. Методика измерения для сетей TDM известна как спецификация ITU-T G.821. Классически для проверки каналов используется BERT (BER Test) первого уровня, но с учетом специфики работы протоколов инкапсуляции пакетных сетей и самого принципа работы пакетных сетей необходимо иметь возможность проводить тесты на L1-L4. Немного далее будет рассмотрено подробнее. Ну а сейчас следует определиться что проверять и как проверять. На вопрос:” Что проверять?” Отвечает ITU-T 0.150. В его пункте 5 рассмотрены типы ПСП (псевдослучайных последовательностей), из которых просто берутся данные для формирования пакета. Т.е. нужно просто взять и заполнить соответствующий уровень пакета данными выбранной ПСП. У нас в приборах используются следующие ПСП:

• ПСП 2е9 (ITU-T 0.150 пункт 5.1)
• ПСП 2е11 (ITU-T 0.150 пункт 5.2)
• ПСП 2е15 (ITU-T 0.150 пункт 5.3)
• ПСП 2е23 (ITU-T 0.150 пункт 5.6)
• ПСП 2е31 (ITU-T 0.150 пункт 5.8)
• пользовательская последовательность (32 бита)
• все нули
• все единицы
• альтернативная последовательность (01010101)

Пользовательская последовательность введена для совместимости с приборами, которые существуют на рынке, т.е можно задать любую последовательность и проводить совместный тест.

Вопрос как проверять пока что открыт, попробуем разобраться. Допустим мы умеем генерировать определенные пакеты. Если отправить такой пакет на другой конец транспорта, то как понять, что он не изменился (следует абстрагироваться от пакетного принципа, поскольку у нас может не быть FCS и других типов контроля, как описано ранее)? Самый простой вариант — завернуть пакет обратно (в TDM называется “сделать петлю”, в Ethernet — установить шлейф). Заворот, во многих случаях, можно сделать на выходе канала без изменения среды передачи, т.е. реально поставить петлю на выходе E1 и все будет работать. Но т.к. данные проделывают двойной путь, то вероятность возникновения ошибки также возрастает в 2 раза. Да и каналы могут быть асимметричными или однонаправленными. Соответственно идеальным было бы иметь возможность обладать информацией о корректном следовании и сравнивать приходящие пакеты с уже известной информацией. Первый, и наиболее простой вариант, применимый когда оба выхода канала располагаются рядом (например такое возможно при TDM коммутации, или тестировании оптического “кольца”) заключается в том, что один порт прибора генерирует тестовый трафик, а другой порт этого же прибора его получает и сравнивает, а т.к. сравнение происходит в том же узле, что и генерация, то проблем со сравнением данных последовательности не возникает. Второй вариант предполагает восстановление первоначальной последовательности и сравнение ее с приходящими данными. В случае с полностью случайной последовательностью реализовать такое не представляется возможным, а вот если последовательность псевдослучайная, то вполне. Какое-то время затрачивается на синхронизацию в самом начале теста, но затем сравнение не представляет сложности. Поскольку ПСП первого прибора и ПСП второго известны и одинаковы, синхронизация сводится к поиску места начала сравнения в ПСП второго прибора. Таким образом существуют следующие топологии:

1. «сам на себя» 1 — один прибор на одном порту, на другом конце транспорта стоит шлейф
2. «сам на себя» 2 — один прибор с одного порта своего порта на другой свой порт
3. с одного прибора на другой прибор, с синхронизацией

Еще раз стоит отметить, что тест BER не рекомендуется использовать на сетях лишь с пакетной коммутацией. Приведу пример. Допустим, уже идет тестовый поток и приборы синхронизированы (топология 3). В какой-то момент времени происходит следующее:

1. формируется Ethernet-фрейм, содержащий данные ПСП
2. для такого фрейма рассчитывается FCS и он укладывается в выходной буфер
3. фрейм отправляется по сети на другой прибор
4. по каким-то причинам происходит изменение всего одного бита внутри пакета
5. получатель принимает пакет
6. FCS принятого пакета не соответствует содержимому
7. пакет отбрасывается (если между отправителем и получателем есть, например, коммутатор, то “кривой” пакет вообще не дойдет до получателя, т.к. будет уничтожен до него)
8. отправитель формирует следующий пакет (все начинается с п.1)

В приведенном примере на шаге 8 произойдет срыв синхронизации на стороне получателя. Произойдет это потому, что отправитель возьмет следующий блок ПСП, а получатель будет сравнивать с тем блоком, который потерялся в предыдущем цикле (он ведь ничего не знает о потере). Срыв синхронизации приведет к необоснованно большому росту битовых ошибок, т.к. все вновь идущие блоки абсолютно не совпадают, что приведет к тому, что за один пакет число битовых ошибок будет увеличиваться на размер фрейма. Через какое-то время будет предпринята попытка восстановления синхронизации, но количество накопленных битовых ошибок будет сильно не соответствовать действительности.

А как в железе?

Как у других не знаю, но у наших приборов Беркут (ET, ETX, ETL, B100, а также модуль B5-GBE для MMT) дела обстоят следующим образом. Помня принцип о генерации и анализе трафика как можно ближе к физическому сегменту из первой статьи, все подобные задачи были возложены на FPGA. Упрощенная структурная схема выглядит так:

MAC ядро представлено двумя блоками: один на прием, другой на передачу. Это позволяет независимо принимать и отправлять пакеты, т.е. нет взаимовлияния очереди отправки на очередь приема и наоборот. Также с двух независимых блоков возможно вести общую статистику по полученному и отправленному трафику независимо от типа теста. Данные с блока передачи поступают на трансмиттер и отправляются в сеть, а входящие данные с трансивера поступают в блок приема.
Поскольку для некоторых топологий тестов необходим функционал шлейфа (loopback, петля), то он реализован отдельным блоком. Возможно установить шлейф уровня L1-L4:

• L1 — просто заворачивает трафик обратно (происходит это еще в трансивере)
• L2 — меняет DstMAC<->SrcMAC местами, пересчитывает FCS
• L3 — меняет DstMAC<->SrcMAC и DstIP<->SrcIP местами, пересчитывает FCS
• L4 — меняет DstMAC<->SrcMAC, DstIP<->SrcIP и DstPort<->SrcPort, пересчитывает FCS

Статистика по пакетам ведется и для режима шлейфа тоже, что позволяет грубо оценить соотношение отправленных и принятых пакетов.

Модуль генератора для каждого типа теста свой, для BERT он содержит генератор ПСП всех заявленных типов.
Работает это следующим образом. От генератора ПСП поступают данные на мультиплексор (проще говоря коммутатор), который, если не включен какой-то другой канал в данный момент, направляет поток в MAC tx модуль. MAC tx модуль, в соответствии с настройками теста (уровень BERT, размер пакета, данные полей) формирует из ПСП валидный Ethernet-фрейм и отправляет его в трансивер, который в свою очередь отправляет его в сеть. В зависимости от топологии теста фрейм либо заворачивается удаленной стороной, либо анализируется. В любом случае первичная обработка пакета не отличается. Фрейм попадает на MAC rx ядро, которое отправляет его на мультиплексор. Мультиплексор в зависимости от режима работы прибора направляет пакет либо в Loopback модуль, откуда после обработки он сразу же направляется в MAC tx для отправки, либо в модуль обработки и статистики теста, где, если потребуется, будет проведена попытка синхронизации ПСП и выполнено сравнение исходной последовательности с полученной. Результаты обработки отдаются в модуль вывода статистики.
Использование FPGA или ASIC позволяет все операции проводить параллельно, что не вносит какие либо задержки на обработку и исключает взаимовлияние модулей обработки.

Заключение

Несмотря на всю кажущуюся простоту алгоритмов и методик, за ними стоит много лет серьезных исследований. Огромное число факторов до сих пор влияет как на точность измерений, так и на стоимость приборов (прецизионные элементы, высокоскоростные ПЛИС). Например, приведенный выше BER тест не отличается значительной сложностью в общем алгоритмическом плане, но требует знаний в области математики, информатики и теории информации для разработки жизнеспособной модели. Модификация BER теста для пакетных сетей (поддержка уровней L2-L4) требует глубокого понимания принципов коммутации и маршрутизации. Надеюсь, что подобного рода статьи интересны и приносят пользу. В следующих публикациях планирую написать про сертифицированные тесты, генераторы трафика, фильтры и аналитические комплексы. Ведь как сказал Джон Фицджеральд Кеннеди на выступлении перед гражданами США перед стартом Лунной программы:

“И мы сделаем это. Не потому, что это легко, а потому что трудно.”

_{PS. Задавайте вопросы и предлагайте темы, в рамках нашей компетенции готовы на все}