Fcs ошибки на порту

Столкнулся с проблемой на MikroTik – ошибки в логах и отсутствие интернета на порту Ether1. Стал искать ответ в интернете, но решения не нашел. Существует предположение, что проблема появления ошибки interface,warning ether1 fcs error on link связана с наводками от кабелей 220v.

К сожалению, проблема не имеет стойкого графика появления. Цикл между ошибками разный, может быть неделя, а может быть и пару месяцев. Помогает либо полная перезагрузка MikroTik или отключение порта. До текущего момента мы делали это вручную, после был найден скрипт. К сожалению автора скрипта, найти не удалось. Но раз ошибка популярная, то думаю не лишним будет его указать, как решение проблемы.

На микротике RB951G-2HnD установлена последняя RouterOS 6.19.
Провайдер (Ростелеком) подключен в первый порт роутера, скорость соединения в микротике определяется, как 100 full duplex.

При поднятии PPPoE соединения с провайдером теряется около 40% пакетов через это соединение. Пробовал ping 8.8.8.8 и ping ya.ru и просто открывал сайты через http.

Важно, что при использовании старого оборудования (сервер на Intel Atom) таких потерь не обнаруживается. Пробовал подключать ноутбук с Ubuntu напрямую тоже все работает без проблем.

Что делал:
Менял MTU PPPoE соединения и flow control Ethernet port1.
Менял роутер для исключения не работоспособности железа.
Менял физический порт роутера на 5й эффект сохранялся.
На форуме микротика нашел схожую проблему, которая якобы исправлена в версии 6.11 RouterOS.

Также как и предложено на форуме микротика включил между микротиком и провайдером Dlink-DGS 1005d и потери пакетов исчезли.

Как исправить проблему с потерей пакетов? Хочу подключать напрямую, а не через доп. оборудование.

суббота, 27 декабря 2014 г.

Значения счетчиков ошибок

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

Счетчики ошибок при получении кадров (RX):

CRC Error

Counts otherwise valid packets that did not end on a byte (octet) boundary.

Счетчик ошибок контрольной суммы (CRC). В свою очередь, является суммой счетчиков Alignment Errors и FCS Errors.
FCS (Frame Check Sequence) Errors — ошибки в контрольной последовательности кадра. Счетчик регистрирует кадры с ошибками FCS, при этом кадры имеют корректный размер (от 64 до 1518 байт) и получены без ошибок кадрирования или коллизий.
Alignment Errors — ошибки выравнивания (некорректной длины кадра). Счетчик регистрирует кадры с ошибками FCS, при этом кадры имеют корректный размер (от 64 до 1518 байт), но были получены с ошибками кадрирования.
В случае, если кадр был классифицирован как имеющий ошибку Alignment Error, счетчик FCS при этом не увеличивается. Иными словами, инкрементируется либо счетчик FCS либо Aligment, но не оба сразу.

UnderSize

The number of packets detected that are less than the minimum permitted packets size of 64
bytes and have a good CRC. Undersize packets usually indicate collision fragments, a normal
network occurrence.

Счетчик кадров с правильной контрольной суммой и размером менее 64 байт. Такие кадры могут возникать в результате коллизий в сети.

OverSize

Counts valid packets received that were longer than 1518 octets and less than the
MAX_PKT_LEN. Internally, MAX_PKT_LEN is equal to 1536.

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

Fragment

The number of packets less than 64 bytes with either bad framing or an invalid CRC. These
are normally the result of collisions.

Счетчик кадров с неправильной контрольной суммой или структурой кадра и размером менее 64 байт. Такие кадры могут возникать в результате коллизий в сети.

Jabber

Counts invalid packets received that were longer than 1518 octets and less than the
MAX_PKT_LEN. Internally, MAX_PKT_LEN is equal to 1536.

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

Счетчик ошибок при отправке кадров (TX):

Excessive Deferrral

Counts the number of packets for which the first transmission attempt on a particular
interface was delayed because the medium was busy.

Счетчик кадров, первая попытка отправки которых было отложена из-за занятости среды передачи.

CRC Error

Counts otherwise valid packets that did not end on a byte (octet) boundary.

Счетчик ошибок контрольной суммы (CRC). На практике никогда не увеличивается.

Late Collision

Counts the number of times that a collision is detected later than 512 bit-times into the
transmission of a packet.

Счетчик случаев когда коллизия обнаруживалась после передачи первых 64 байт (512 бит) кадра.

Excessive Collision

Excessive Collisions. The number of packets for which transmission failed due to excessive
collisions.

Счетчик кадров, отправка которых не удалась из-за чрезмерного количества колизий.

Single Collision

Single Collision Frames. The number of successfully transmitted packets for which
transmission is inhibited by more than one collision.

Счетчик успешно отправленных кадров, передача которых вызвала более одной коллизии.

Collision

Моно добавить, что на практике RX CRC обычно является результатом деградации среды передачи (медный кабель или оптоволокно), а TX-коллизии — результатом неправильного согласования скорости соединения, например half-линка.

Неплохая расшифровка значений счетчиков приведена тут.

Introduction

This document describes how to understand errors from devices connected to Multigigabit Ethernet (mGig) ports on Catalyst 9000 Series Switches. 

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

The information in this document is based on these platforms: Catalyst 9000 series switches with mGig capable ports. 

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, ensure that you understand the potential impact of any command. 

Background Information

This document describes why you can encounter frame check sequence (FCS) errors, input errors, or packet loss with devices that connect to Multigigabit Ethernet (mGig) ports on Catalyst 9000 series switches due to interpacket gap (IPG) or interframe gap (IFG) tolerance. 

In networking, a pause could be required between network packets or network frames. This time between packets is known as the IPG or IFG. This pause is necessary to allow for receiver clock recovery, which permits the receiver to prepare for another packet. The IFG/IPG standard value for Gigabit Ethernet is 12 bytes. However, from  IEEE Standard 802.3, the minimum value for the IFG can be as low as 8 bytes or 64 BT (bit times). For reference, this is documented in 802.3-2000 — IEEE Standard for Information Technology — LAN/MAN — Specific Requirements.

Problem Summary

Multigigabit Ethernet technology is implemented on 10Gig PHYs on Cat9000 architecture. For example, when a connection is established through an mGig port at 1Gbps, if traffic bursts higher than the bandwidth of the interface, the C9600 utilizes port buffers to accommodate that excess traffic and dynamically decreases the IFG/IPG size to avoid any impact and ensure traffic throughput and switch performance. The issue arises when some peer devices are unable to handle the smaller IFG/IPG sizes and no longer recognize legitimate packets and drop this traffic, which results in input errors on their NIC or PHY, such as Cyclic Redundancy Check (CRC) or FCS errors. In certain scenarios the local mGig port (an interface from the mGig linecard C9600-LC-48TX) can also experience the same type of loss in the form of input errors (CRC, FCS) on the interface.

As shown in the table, the structure of an Ethernet packet, which includes the IPG/IFG field:

Software Changes 

Cisco has made changes to software for mGig capable Catalyst switches to accommodate devices that do not tolerate variance in the IPG/IFG. These changes are documented in various Cisco bug IDs.

Note: Only registered Cisco clients can access the bugs listed in this document.

Workarounds 

In some cases, these interoperability issues can be mitigated through hard-coding the mGig port to a lower speed (100Mbps vs 1Gbps), utilization of a different speed (100Mbps or 10Gbps vs 1Gbps), or the affected device is moved to a non-mGig capable port.

Fcs error on link mikrotik что это

Sun Dec 29, 2019 10:32 pm

My network completely stopped. Couldn’t get anything to work. Couldn’t statically set an IP and reach the router.

Rebooted router. nope.
Noticed even my caps had stopped transmitting.

Rebooted switch. Everything came back.

Looked at the log from my router.
Sfp-sfpplus1 fcs error on link

After rebooting the switch.
Sfp-sfpplus1 link down
Sfp-sfpplus1 link up (Speed 10G, full duplex)

Few seconds later. Everything got IP addresses and returned to normal.

Re: FCS error on link

Sun Dec 29, 2019 10:42 pm

Re: FCS error on link

Sun Dec 29, 2019 11:39 pm

Unit had been in operation for a few weeks at this point.

During lockup.
It still provided POE to a hAP AC2 and to a 5 port 260.

Re: FCS error on link

Mon Dec 30, 2019 9:38 am

Re: FCS error on link

Mon Dec 30, 2019 6:02 pm

Re: FCS error on link

Mon Dec 30, 2019 7:21 pm

Re: FCS error on link

Mon Dec 30, 2019 7:22 pm

Re: FCS error on link

Mon Dec 30, 2019 8:16 pm

Re: FCS error on link

Mon Dec 30, 2019 11:10 pm

The FCS error was what the router was reporting when the switch was locked up.

That cable had been used before with another manufacture’s switch, and the switch never locked up.

The cable is a direct connect type where the modules that go into the router and switch are part of the cable.

I was hoping I was providing meaningful data that could be used to CORRECT whatever made this happen.

And remember. This is the first time I observed this problem at the office, and the system had been running for over a week. Infact. It was working one second then not. I was watching something on Amazon Prime on my computer at the time. I only noticed when the error screen popped up.

Источник

Fcs error on link mikrotik что это

ether2 fcs error on link

У меня такая же ошибка уже месяца полтора-два.
Делал то что и Вы, менял провода, порты, настройки.
Ждал новую прошивку, в ней было описание что вроде это пофиксили,
но увы, снова и снова. ошибки есть.

Кстати, думаю что это связано с насхлёстом одного уровня над другим.
У меня получается сделан бондинг (ether1 и ether2) , на этом бондинге подняты виланы (много) и уже на виланах идёт адресация. Также туннели висят на некоторых адресах.
Думаю что из-за вот этих 2х уровней абстракции + туннели и возникает. проблемы.

В другой конторе почти на 80% такая же конфигурация, но там ошибок нет. Так что думаю или дело в туннелях (там их нет, а бондинг и виланы есть),
или всё же с другой стороны микротика, на свиче что-то с портами Ethernet (мож свитч подыхает?)

Опишите Вашу конфигурацию. может найдём общие точки соприкосновения!?

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

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

Источник

Fcs error on link mikrotik что это

Sun Oct 04, 2015 4:12 pm

Yesterday replaced a rb1100AH running v.6.30.2 to a brand new CCR1009-8G-1S-1S+ router.

Looked in the log today and found it filled with fcs errors?

All ethernet cables are almost new and connect to new routers and on the rb1100AH showed no errors and were Gigabit connected (auto negotiation on)

Now these failures?
I installed the CCR with 6.32.2 but reverted back to 6.30.2 as the most stable version but the problem didn’t disappear.

1. It can’t be the cables, they were all fine on the rb1100AH and basically all new.
2. It can’t be the software? 6.32.2 or 6.30.4 makes no difference. And most of my other routers now work fine with either one of these two versions.

I ran 2 ping tests with 100ms timeout to adjacent router and that is fine. 1st is 100ms and 50 bytes packet size, 2nd is 100ms but 1500 packet size. On the latter I see an occasional time out and I see 1% package loss.
The stats of the interface is also showing the error. 2100 errors in 25 mins uptime.

Do I have a failing CCR? Where is this error coming from?

Show your appreciation of this post by giving me Karma! Thanks.

WISP operator based on MT routerboard & ROS.

Re: fcs error on new CCR1009

Tue Oct 06, 2015 11:19 am

Show your appreciation of this post by giving me Karma! Thanks.

WISP operator based on MT routerboard & ROS.

Re: fcs error on new CCR1009

Tue Oct 06, 2015 7:37 pm

Three things cause FCS errors typically, with the first two being the most likely.

1) Physical cabling issues

2) Speed / duplex mismatch or errors

Steps to resolve.

1) Change the cable with a known good one on the link you are getting FCS and reset counters.

2) Hard code speed and duplex to match on both sides of the link.

3) Move to the bugfix version — 6.30.4 as it is the most stable version for ROS right now in general

Re: fcs error on new CCR1009

Tue Oct 06, 2015 7:50 pm

be sure you have updated the firmware (not routeros)

put a manageable switch as a bypass on that link to see if switch receives the same errors

Re: fcs error on new CCR1009

Tue Oct 06, 2015 8:14 pm

Three things cause FCS errors typically, with the first two being the most likely.

1) Physical cabling issues

2) Speed / duplex mismatch or errors

Steps to resolve.

1) Change the cable with a known good one on the link you are getting FCS and reset counters.

2) Hard code speed and duplex to match on both sides of the link.

3) Move to the bugfix version — 6.30.4 as it is the most stable version for ROS right now in general

Show your appreciation of this post by giving me Karma! Thanks.

WISP operator based on MT routerboard & ROS.

Re: fcs error on new CCR1009

Wed Oct 07, 2015 5:35 pm

Really sounds like you may have a bad board out of the box. few comments below

1) If you can swap the 1100 back in and the FCS goes away, then i would agree cabling is prob not it

2) This is true only on copper (and you can set 100M Full on each side just for testing) SFP ports can be hard coded to 1000/Full as well.

3) In our lab we have a CCR1009 connected to MikroTik, Cisco and HP network equipment on copper and fiber without issue. unfortunately you probably got a bad CCR.

There was a batch of bad CCR1009s early on and it’s possible you got one that’s been on the shelf for a while as all the new CCR1009s shipping seem to be pretty solid.

Re: fcs error on new CCR1009

Wed Oct 07, 2015 6:49 pm

Re: fcs error on new CCR1009

Thu Oct 08, 2015 11:53 am

Nailed the issue for 95%:

All links / ethernet cables leave from CCR1009 over some 15 meter of ftp cable (all well grounded on both ends. ) to a tower cabinet.
In the cabinet a 24V PoE battery fed midspan power inserter with lighting/surge protector is fit. From here some 8-10 meter of ftp (all well grounded on both ends. ) run up the tower to connect to the radios. Mostly Netmetals.

The midspan PoE injector is from Cyberteam, Poland. This is a managed Gigabit version. This is actually the 3rd box that give me problems. One just died, the second had no more webserver working and became useless because of that en this last one after 2 months again fell without web server control. So my suspicion went to this device. Last night I replaced it to a brand new unmanaged gigabit net-protector and almost all fcs error disappeared from the logs.
So this is the 3rd managed netprotector heading for the bin (with 2 unmanaged going the same before. poor quality stuff. )

I still suspect the last remaining errors, now only on one link, are due to this new netprotector. But to be honest there are not a lot 24V multiple port passive PoE midspan injectors in gigabit version with IP management on the market. The nearest solution I can find are Netonix WISP switch but I need to convert it into 1:1 port to port switch only since the several routes have different dhcp-servers and hence these ‘pipe’s need to stay separated.

To reply to some of your comments;

3) In our lab we have a CCR1009 connected to MikroTik, Cisco and HP network equipment on copper and fiber without issue. unfortunately you probably got a bad CCR.

There was a batch of bad CCR1009s early on and it’s possible you got one that’s been on the shelf for a while as all the new CCR1009s shipping seem to be pretty solid.

Show your appreciation of this post by giving me Karma! Thanks.

WISP operator based on MT routerboard & ROS.

Re: fcs error on new CCR1009

Thu Oct 08, 2015 11:56 am

Show your appreciation of this post by giving me Karma! Thanks.

WISP operator based on MT routerboard & ROS.

Re: fcs error on new CCR1009

Thu Oct 08, 2015 3:31 pm

Last night at around 1 am we replaced the gigabit netprotector (Poe midspan injector) for another more simple one (Also giga, also Cyberteam, but no remote access, no control whatsoever) brand new out of the box.
Immediately after the change the fcs errors didn’t come back. Well, instead of every 30 seconds until this morning 10 am when I logged in again the log only showed 4 fcs errors in total since the change. good!
. You would think. =>

While looking over a remote winbox session in this CCR1009’s log this morning I saw the errors coming back! First every 10 mins, then every 5 mins, every 3-4 mins and now they are back to every 2 mins.
How is this possible? Overnight the problem vanished just to come back in the morning. Very, very weird.

I don’t know what to do now. Cannot go to 100mbps setting on each end since this is my main backhaul that at times has more traffic than 100mbps. Fast Ethernet will create a bottleneck again. (I spend a lot of time and money and energy into reforming a previously duo bonded link with double antenna sets etc. high in towers into a ‘ac’ single 40Mhz wide link to get up to 300Mbps over this new link. (tested up to 280M!)

I also cannot fit in the gigabit power inserters from Mikrotik. Because the poe insert is in the middle of a cable. Both ends need to be at least 10 meters.
I don’t seem to be able to find any passive poe midspan inserters that work on 24V battery power and have gigabit port and are remotely controllable.

So, main question; Until I find any solution, how bad is it these errors are there? They fill the log, but do they have any other harm? I don’t seem to notice problems (yet?). Ping on long and short package see no losses and ping times are good and traffic flows.
But out of the 12 NetMetals installed over the last weeks, all running with latest ROS and firmware in bridge mode (fastpath enabled) I have 3 of them that just stop passing traffic once a 2 or 3 weeks. only a power reboot brings these back in working order again. Can this have anything to do with some fcs error too? (Since the Netmetals don’t show these errors in the logs I never looked for them. )

Show your appreciation of this post by giving me Karma! Thanks.

WISP operator based on MT routerboard & ROS.

Источник

Fcs error on link mikrotik что это

Mon Apr 10, 2017 12:28 pm

Yesterday (the same as before about 3/4 year) to WAN IFC CCR appeared on «FCS Error on interface» error. At that time we thought it was a fault mikrotik and did not pay it much attention.

IFC could turn and errors disappeared.
But this morning it appeared again and turning the IFC, it decides not solved During the 15 minutes it was so 1260 RX FCS Error statistics IFC.
Thus, unlike the day before yesterday against a «Back then» was that the IFC normally ping and communication over IP function (the question of how long it would take).

What we tried:
1) gradually turn off IP addresses in an attempt to isolate the communications that fall — without success, they doing it all
4) disable IFC and after a while switch on — no Results

Finally, in this case helped disable all addresses in Adress list and gradually one by one turn on, turn off, then turn the other one on and off, to turn each of them has always been for a while primary address, at that moment dana address is always started from the outside Ping this style we all eventually turned and began to work, but not a solution.

Yesterday, on the recommendation of the man in our housing turn off Auto negotiation on an Ethernet port, and set to fix 100Mbit full duplex.
When I turned on him again today (auto negotiation) and FCS Error disappeared (according to IFC well log set 100Mbit Fullduplex)
So I think it’s some kind error somewhere .
Technic guy said he had also solved it with Mikrotik and that was just a problem in that the IFC runs at 100Mbit — which is the only difference from previos housing (there was 1Gbit O2 is 100 Mbps per line)
Netwatch meanwhile is set to GW and if there is a timeout 5s (once per minute), and it turns IFC WAN (it solves unavailability), but does not generally FCS Error.

So if it happens again, there will be an interesting test by me throw it on the RB2011 or whatever it is, because he has a physical 100Mbit interfaces. Optionally upgrade from 100Mbit to 1Gbit (which is unnecessary, peak traffic was 35Mbit)
I must say that on the other (admin router — the RB2011) it has not happened yet not once — there is a 100Mbit link, so maybe it’s best estimate

What do you think?

log:
.
xxxx interface,warning ether1 — WAN fcs
error on link
xxx interface,warning ether1 —
WAN fcs error on linkxxxx interface,warning
ether1 — WAN fcs error on linkxxxx
interface,warning ether1 — WAN fcs error on link
xxxx
xxx interface,warning ether1 — WAN fcs error on linkxxxx interface,warning ether1 — WAN fcs error
on link
.

Источник

Ethernet

Sub-menu: /interface ethernet
Standards: IEEE 802.3

MikroTik RouterOS supports various types of Ethernet interfaces — ranging from 10Mbps to 10Gbps Ethernet over copper twisted pair, 1Gbps and 10Gbps SFP/SFP+ interfaces and 40Gbps QSFP interface. Certain RouterBoard devices are equipped with a combo interface that simultaneously contains two interface types (e.g. 1Gbps Ethernet over twisted pair and SFP interface) allowing to select the most suitable option or creating a physical link failover. Through RouterOS, it is possible to control different Ethernet related properties like link speed, auto-negotiation, duplex mode, etc, monitor a transceiver diagnostic information and see a wide range of Ethernet related statistics.

Properties

Read-only properties

Menu specific commands

Monitor

To print out a current link rate, duplex mode, and other Ethernet related properties or to see detailed diagnostics information for transceivers, use /interface ethernet monitor command. The provided information can differ for different interface types (e.g. Ethernet over twisted pair or SFP interface) or for different transceivers (e.g. SFP and QSFP).

Properties

Example output of an Ethernet status:

Example output of an SFP status:

Detect Cable Problems

A cable test can detect problems or measure the approximate cable length if the cable is unplugged on the other end and there is, therefore, «no-link». RouterOS will show:

• which cable pair is damaged
• the distance to the problem
• how exactly the cable is broken — short-circuited or open-circuited

This also works if the other end is simply unplugged — in that case, the total cable length will be shown.

Here is an example output:

In the above example, the cable is not shorted but “open” at 4 meters distance, all cable pairs are equally faulty at the same distance from the switch chip.

Currently cable-test is implemented on the following devices:

• CCR series devices
• CRS1xx series devices
• CRS2xx series devices
• OmniTIK series devices
• RB450G series devices
• RB951 series devices
• RB2011 series devices
• RB4011 series devices
• RB750Gr2
• RB750UPr2
• RB751U-2HnD
• RB850Gx2
• RB931-2nD
• RB941-2nD
• RB952Ui-5ac2nD
• RB962UiGS-5HacT2HnT
• RB1100AHx2
• RB1100x4
• RBD52G-5HacD2HnD
• RBcAPGi-5acD2nD
• RBmAP2n
• RBmAP2nD
• RBwsAP-5Hac2nD
• RB3011UiAS-RM
• RBMetal 2SHPn
• RBDynaDishG-5HacD
• RBLDFG-5acD
• RBLHGG-5acD

Note: Currently cable-test is not supported on Combo ports.

Stats

Using /interface ethernet print stats command, it is possible to see a wide range of Ethernet-related statistics. The list of statistics can differ between RouterBoard devices due to different Ethernet drivers. The list below contains all available counters across all RouterBoard devices. Most of the Ethernet statistics can be remotely monitored using SNMP and MIKROTIK-MIB.

For example, the output of Ethernet stats on the hAP ac2 device:

Источник

Сообщения без ответов | Активные темы

Автор	Сообщение
	Заголовок сообщения: От чего на порту комутатора могут появлятся FCSErrors ? Добавлено: Ср июн 25, 2008 11:32
Зарегистрирован: Вт май 16, 2006 13:02 Сообщений: 867 Откуда: Ukraine	Простая связка, DES3526 —— COMPEX8——COMPEX8——DES1226G На 3526 порт, что смотрит на первый COMPEX8 Received(RX) есть такие ошибки не очень много, и потом на порту DES1226G что смотрит на COMPEX8 тоже в Received(RX) есть ошибки но уже по больше. Мыльницы менялись на новые, ситуация не поменялась. Между ними всеми витая пара до 100 метров FTP. Свободные пары в витой паре между КОМПЕКСАМИ заземлены жёстко на землю, в одной точке, а так же от дельно заземлены 3526 и 1226 в своих местах установки. Так же стоят грозозащиты на всех магистральных портах..
Вернуться наверх

Demin Ivan	Заголовок сообщения: Добавлено: Ср июн 25, 2008 11:50
Зарегистрирован: Пт май 13, 2005 15:49 Сообщений: 20616 Откуда: D-Link, Moscow	Вообщем по какой-то причине приходит небольшое кол-во битых пакетов. Настройки портов на обоих концах линка полностью совпадают?
Вернуться наверх

kapa	Заголовок сообщения: Добавлено: Ср июн 25, 2008 12:00
Зарегистрирован: Чт сен 28, 2006 12:07 Сообщений: 220 Откуда: Москва	грозозащиты менять (убирать) пробовали?
Вернуться наверх

MsHOME	Заголовок сообщения: Добавлено: Ср июн 25, 2008 18:16
Зарегистрирован: Вт май 16, 2006 13:02 Сообщений: 867 Откуда: Ukraine	Менять или убирать грозозащиты не пробовали, ибо стрёмно. Значит говорите что дело может быть в них, я подумаю, спасибо.
Вернуться наверх

MsHOME	Заголовок сообщения: Добавлено: Ср июн 25, 2008 18:17
Зарегистрирован: Вт май 16, 2006 13:02 Сообщений: 867 Откуда: Ukraine	Demin Ivan писал(а): Вообщем по какой-то причине приходит небольшое кол-во битых пакетов. Настройки портов на обоих концах линка полностью совпадают? Как видите настроить порты можна только на оконечных устройствах и там оно стоит в автоматическом режиме.
Вернуться наверх

kapa	Заголовок сообщения: Добавлено: Пт июн 27, 2008 08:02
Зарегистрирован: Чт сен 28, 2006 12:07 Сообщений: 220 Откуда: Москва	MsHOME писал(а): Менять или убирать грозозащиты не пробовали, ибо стрёмно. Значит говорите что дело может быть в них, я подумаю, спасибо. Даже, если они исправны, то дело моет быть в них. Например, линк 100м — по стандарту, а вы с обоих сторон вносите дополнительное сопротивление грозозащитами -> сигнал слабеет.
Вернуться наверх

MsHOME	Заголовок сообщения: Добавлено: Пт июн 27, 2008 11:09
Зарегистрирован: Вт май 16, 2006 13:02 Сообщений: 867 Откуда: Ukraine	Согласен, в тех описании грозозащит описано, что вносимые затухания равны 10 метрам кабеля. Спасибо за советы, пока количество ошибок не критично, если будут более не стабильны то заменю линки на оптику.
Вернуться наверх