Приветствую!

Никогда на практике не сталкивался с передачей данных по сети Ethernet. И вот...

Задача довольно простая. Имеется устройство (нашей разработки), которое с помощью
ПЛИС снимает данные со 128 датчиков. Затем эти данные нужно передать в компьютер
для последующей обработки.

Имеется два основных требования, которые ставят меня в тупик:

1. Скорость поступающих данных 100+ мбайт/сек. (не мбит!).
2. Расстояние от устройства до компьютера 100-300 метров.
3. Соединение типа точка-точка.

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

Далее. Примерно прикинул, что канала на 1 Гигабит должно хватить. Данные передавать
по протоколу UDP (я прочитал, что он обеспечивает максимальную скорость передачи).
В нашем устройстве не хотелось бы использовать какую-то серьезную аппаратную часть
(типа PC-материнки). Было бы желательно обойтись просто чем-то вроде RTL80xx или
подобным, с минимальной дополнительной обвязкой. Может быть поставить простой
микроконтроллер для конфигурирования всего этого хозяйства.

На компьютерной стороне у заказчика стоит PC с Виндой. Мне нужно будет написать
простую DLL-ку, которая примет поток данных и положит их куда прикажут (в файл на диск,
запихнет в Memory Mapped File и т.п.).

Исходя из вышеизложенного имеются следующие вопросы:

1. На какую аппаратную базу в устройстве следует закладываться? Видимо примененная
микросхема продиктует требуемый протокол передачи? Наверное устройства вроде W5300
фирмы WIZnet не подойдут по скорости, а другие не имеют аппаратной реализации TCP, UDP?

2. Как под Виндой получать переданные данные? Понятно, что TCP, UDP можно получать
с помощью Winsock, а если протокол более низкого уровня, тогда чем? Тем же Winsock-ком?

Спасибо!

Тогда совет - не беритесь за эту работу. Слишком высокая планка для начала. Причем про использование на встречной стороне любой произвольной машины с win или чем либо еще десктопно-ширпотребным следует сразу забыть. Сформировать и вдуть Ethernet фреймы (а ничего другого Вам не надо) на указанной скорости из FPGA особо явных проблем не должно быть. Поминание всяких слов типа "Wiznet" в конетксте озвученного задания, абсолютно ни о чем.

Хм... Неужели эта задача настолько сложна? Речь-то всего о канале вроде обычного COM-порта, только очень быстром :-) Соединение точка-точка. Все остальное в Мире Интернета и сетей данной задачи не касается. Устройство данные генерит - достаточно мощный PC-шник принимает и все.


Безусловно! Этот вопрос будет согласован с заказчиком. Понятное дело, что работать с таким потоком данных - это не офисная задача. Предварительно я уже обговорил с ними насчет размера и скорости потока. Встретил понимание. Если понадобится, между порциями данных будут введены небольшие паузы.


Во, во. Подскажите пожалуйста, как это по-проще сделать? Какую элементную базу лучше применить? По какому протоколу передавать и принимать данные?

Да. Для начинающего наверняка не подъемна, если речь идет о каких-то реальных сроках.

Великолепно. Думаю, что у Вас найдется пара PC с Windows. Попробуйте для начала переслать и писать на диск эти самые 100 мегабайт в секунду.

Голый PHY - это очевидно.

Уже писал - просто Ethernet фрейм. Минимально-достаточное условие для стыковки с готовой гигабитой оптикой на встречной стороне.

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


Да, я как раз об этом задумывался. Даже начал ваять пробную пару клиент-сервер. Только пока не разобрался, как передавать данные по протоколам более низкого уровня относительно UDP. Спасибо за подсказку!


Я попробовал поискать в Гугле. Довольно много всего, туманно пока... Обратил внимание на Intel, но у них, насколько я понял, ориентация на PC с Виндовыми драйверами. Подскажите, пожалуйста, примерное направление, голый PHY каких фирм посмотреть? Чтобы по-проще...

Не подскажу - не занимался гигабитной оптикой. Но в общем это совершенно не принципиально - они достаточно одинаковы, это не MAC. Что-то вроде МАС будете делать в FPGA.

Большое спасибо за помощь! Пошел наковыривать информацию :-) Пока не утратил надежды на решение этой задачи...

..1 Гигабит Ethernet 100 мбайт в секунду не даст - максимум 90 Мбайт/с по UDP.

Да ладно сочинять то!

Все же зависит от размера фреймов..

Вот, например, из Figure 2. можно видеть, что для фреймов с размером больше 512 байт вполне можно передавать 100 МБайт/с и даже поверх TCP/IP.

По этой причине даже UDP использовать не надо, как по причине хоть и малой, но избыточности, и главное, по причине наличия излишеств в виде стека. При использовании допиленного драйвера сетевой карты - можно уже пробовать и под 100 подбираться, ибо 100 мегабайт это 800 мегабит+заголовки+гапы.


Значит можно с интеловской сетевой картой и ее родными драверами под каким-нибудь линуксовым сервером попробовать потестировать.

..может быть, но у нас не получалось , точнее у наших программистов.

А тут результат зависит не только от программистов.

Важны также скорость и обьем жестких дисков, сколько свободного места есть на этих дисках и насколько сильно оно фрагментировано.

Также важны скорость и обьем ОЗУ, рабочая частота ЦПУ, количество посторонних процессов в менеджере задач и прочие ньюансы.

... еще забыли про потери на разъемах, кабелях.

Шутить изволите?

В dB, очевидно?

используйте разбиение по 64 датчика, а не по 128,
и два езернета, а не один.
и всё у вас получится.

Пример для TSE:

Считая, что максимальный размер пакета равен 1500 байт, находим скорость в битах: 8*1500*81270 = 975,24 Mb/s.

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

1)Драйвер и стек две разые сущности и соответственно "переписывая драйвер" ничего в собственно IP стеке не изменить.
2)Полагаю, что сталкивалитсь не с ограничениями на UDP, а на broadcast пакеты.

Ну вообще-то, в природе существуют Ethernet карточки с двумя(!) 10GbE портами: Intel® Ethernet Converged Network Adapter X540-T2.

И раз их выпускают, значит кто-то умеет работать с фулл-дуплексными сетевыми потоками под 20 Gb/s..

Как-то так..

Экая скорость у вас дикая получилось. С Mb не попутали?

У нас по UDP получилось что-то 957 Mb/s, что где-то почти 100% от полезной пропускной для этого протокола. Это по меди порядка 30 м.

Если у ТС на втором конце РС, то UDP, имхо, самый подходящий вариант, голый Ethernet не очень удобен будет.

Попутал, конечно..

Так вот именно в PC c его стеками проблема и есть. Поскольку соединение точка-точка на отдельную сетевую, то повесить на эту сетевую драйвер и на него уже прием фреймов самый простой и независимый путь. Да и если на меньших скоростях в общем потоке работать, то гнать IEEE 802.2 фрейм а не Ethernet II и вытаскивать через RAW без проблем. В противном случае придется на стороне контролера разные не нужные сущности добавлять, типа ARP и заголовков UDP/IP. Не сложно, но прото лишнее.

Приветствую!

У меня Win7 стек нормально пережевывал UDP с двух 10G каналов 1.1 GByte каждый. Так что с 100Mbyte справится.
Естественно для таких целей нужна приличная сетевая карточка.

ТС нужно для начала просто немного поэкспериментировать. Взять тот же iperf или что-то похожее и
протестировать играясь настройками. И прежде чем ваять железо будет понятно чего ожидать
Конечно работать впритык к макс лимиту стремно - всегда есть вероятность потерь пакетов даже при точка-точка - но тут уж TC виднее
какие требования к каналу.
Для снижения трафика можно также задумается над простым сжатием/упаковкой в передатчике раз там FPGA и так стоит -
10% сжатия - и 90MByte уже не так страшны и можно даже какой нибудь протокол натягивать поверх.

Успехов! Rob.

Да, это хорошее предложение.


И во что они "пережевывались" эти 2.2 гигабайта в секунду?

Приветствую!


В кольцевой буфер памяти - это была тестовая машина я на ней отлаживал распаралеливание UDP трафика из FPGA на несколько 10G каналов и последующею сборку на приемной машине для записи.
В рабочей машине на базе Linux работает 4 10G канала в параллель - пишет поток до 4GByte на raid из 32 SSD.

Успехов! Rob.

Спасибо! Понятно.

- Ориентироваться надо на синтезируемые MAC в ПЛИС.
При реализации PHY лучше сразу смотреть в сторону оптических модулей 1G SFP (модули под витую пару тоже можно прикрутить, но надо учитывать, что "вяжутся" они по SGMII).
То, что подается/принимается по дифф. парам оптического модуля SFP - это 1000BASE-X.
1000BASE-X можно получить прямо с ПЛИС (т.е. PHY, точнее PMA, на борту ПЛИС) или от чего-нибудь типа аляски 1111, подключаемой к ПЛИС по GMII.
Для реализации 1000BASE-X PMA на борту ПЛИС могут использоваться как скоростные трансиверы, так и трансиверы LVDS (тут надо смотреть конкретные модели конкретных производителей ПЛИС). Я бы предпочёл сразу ориентироваться на скоростные трансиверы.
Что-нибудь типа относительно недорогих Спартана-6 или Циклона-5 будет самое то.


- Выбор UDP или "сырца" - вопрос скорее философский. Но с точки зрения конечной задачи могут быть преимущества одного или другого.
Для Винды я бы таки ориентировался на UDP и 2 канала 1G с жёсткой привязкой к конкретному типу сетевой карточки на 2 порта.
В части UDP это имха. Будет проще с программерами.
В том, что касается 2 портов, полностью поддерживаю krux чисто из практических соображений:

Не так всё срашно на РС. Если у ТС стоит венда, то там с RAW сокетами не шоколадно, но вполне приемлемо делается на WSA сокетах. На линухе можно через RAW тащить хоть с MAC уровня, но смысла большого нет. Да, поднятие стека хотя бы до UDP требует некоторой возни, зато предоставляет возможность использовать всю сетевую инфраструктуру, что очень удобно и расширяемо. Выбор, конечно, за тем, кому реализовывать.

Большое спасибо, друзья, вы мне здорово помогаете!

Заметно продвинулся в плане понимания проблем, возникающих в ходе работы над поставленной задачей. Попутно пришло осознание, что телепатия, телепортация, левитация - это не просто фантазии. Не знаю насчет телепортации с левитацией, но телепатия точно есть! Иначе как объяснить, что слова уважаемого krux: "используйте разбиение по 64 датчика, а не по 128" попали ко мне в голову именно в тот же вечер, когда он об этом написал! :-)

В результате размышлений, ковыряния в Интернете, чтения различных документов у меня складывается следующая картина:

1. На стороне устройства поставить два канала Ethernet на 1 Гигабит каждый. Для этого использовать микросхему(ы) PHY или реализовать это дело в ПЛИС. Мы как раз используем микросхемы Cyclone V фирмы Altera. Нужно будет посмотреть, что получится проще. Возможно легче будет поставить одну/две микросхемы Ethernet PHY с SRAM-like интерфейсом. Что-то вроде этой: AX88180.

2. К микросхеме(мам) присоединить один/два адаптера для оптики, вроде Antaira SFP-M. Только нужно будет выбрать согласующуюся по интерфейсу пару PHY-оптика.

3. Для управления/конфигурации всего этого хозяйства поставить какой-нить незатейливый микроконтроллер. (Имею опыт работы с Атмеловскими 8-битными МК.)

4. На стороне компьютера поставить двухканальную плату Gigabit Ethernet с соответствующими оптическими согласователями.

Что касается программной части, то мне представляются такие варианты действий:

1. Использовать WinPcap для работы на уровне Ethernet-фреймов. Передавать блоки данных по 1 килобайту с добавлением необходимой информации о каждом блоке (типа, с какого датчика этот блок, коков его порядковый номер и т.п.). Такой вариант не представляет ни малейших проблем.

2. Добавить к передаваемой информации заголовки IP и UDP, тем самым превратив передачу в стандартную для Винды UDP/IP. Эти заголовки можно занести в ПЛИС при конфигурации. Можно даже реагировать на возможные ICMP-сообщения (наверное просто игнорируя их). Тоже сложностей не видно, однако позволяет работать в Винде чисто стандартными средствами. Это - плюс. Минус - это небольшое усложнение каналов передачи со стороны устройства. Это небольшой минус.

Оба варианта предполагают негарантированную доставку пакетов. Однако я надеюсь, что сбои в канале будут достаточно редкими. Поэтому тут мне видится следующий сценарий действий: на компьютерной стороне я учитываю все поступившие пакеты и помечаю, каких пакетов не хватает. Недостающие номера сообщаю микроконтроллеру в устройстве, который инициирует их повторную отправку. Получается такой примитивный TCP. При условии, что потерянных пакетов будет мало, накладные расходы на повторную передачу будут совсем небольшими. Обратный канал от компьютера к устройству мне по-любому нужен. Поэтому его можно организовать по тому же принципу, что и канал от устройства к компьютеру. С той разницей, что тут мне не нужно совсем никакого быстродействия.

Покритикуйте/покомментируйте пожалуйста мои соображения.

Спасибо за помощь!

P.S. Если кто интересуется Windows 10 Insider Preview, то вышел Build 10576. Интересно, откликнулись ли они на многочисленные просьбы инсайдеров выбросить их идиотское упорядочивание All Apps по алфавиту? Счас проверю :-)

Приветствую!

Какой Cyclone V у Вас ?
Если в нем есть MGT то можно сразу делать MAC и PHY внутри и цеплять все сразу напрямую к SFP
Если MGT нет - то МАС делаете в FPGA а снаружи нужен тогда просто внешний PHY типа Marvell 88E1111 или аналог
Cтавить AX88180. я смысла не вижу к нему все равно нужен тот же PHY

В любом варианте генерировать UDP внутри FPGA несложно - простая FSM. Так же как и парсить приходящие пакеты на предмет конфигурации/управления или минимальной поддержки сети (ARP, ICMP) Для этого даже внешний MCU не нужен.

Успехов! Rob.

P.S. вот тут как раз обсуждали PHY

Взглянул на живую плату - сейчас 4-й, EP4CE, ошибся я, думал уже 5-й. Но, полагаю, без проблем поставим и 5-й. Посмотрел по документации - нужно GX. Еще Мегафункцию покупать. С учетом используемых целлов (более 3 тысяч) вполне может получиться, что отдельная микросхема MAC-контроллера с PHY дешевле выйдет.


Тут меня привлекло то, что ее интерфейс больно удобен: просто еще одна память с параллельным 32-битовым интерфейсом. Все знакомо, прозрачно и не нужно заморачиваться с каким-нибудь PCIe.


Мне тоже показалось, что такой вариант для начинающего - самое то.


Большое спасибо!

Однако... Все не так радужно, как мне мечталось... Похоже, что эта AX88180 - единственная на Гигабитную скорость с таким удобным интерфейсом. Черт! Наверное придется использовать альтеровскую мегафункцию (или мегафункции).

Варианты:

1. Установить внутри ПЛИС готовую мегафункцию Ethernet MAC. Настораживает величина стоимости такой мегафункции. Подскажите пожалуйста, сколько эта радость стоит?

2. Использовать Cyclone V со встроенной PCIe внутри. Дополнительно установить внешнюю микросхему Ethernet MAC. Таких чипов достаточно много, есть и двухканальные (что мне как раз и нужно). Что плохо: для того, чтобы выкопать ямку для цветочка приходится вместо совочка использовать шагающий экскаватор... (Это касаемо интерфейса ПЛИС<->Ethernet чип.)

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

Приветствую!


Я понимаю что "нормальные герои всегда идут в обход" но ЗАЧЕМ все пытаться усложнить?!. Так как для PCe нужны такие-же MGT как и для подключения к SFP то надо сразу все в FPGA и делать. - Хотите сэкономить на покупке мегафункции? Тогда надо чуть больше заплатить инженеру чтобы он не только хлебом питался Например можно взять MAC корку и на opencores и допилить для своих нужд.

Но вообще мне кажется тут для начала нужен комплексный анализ требований ко ВСЕЙ системе и вариантов ее построения.
Поскольку вариантов построения может быть масса включая и немного экзотические - например использование что то типа TLK1221
С одной стороны простой параллельный интерфейс - а с другой MGT как раз в SFP. И к тому же на халяву сэмплы шлют
Ну а пакеты инженер сформирует с помощью FSM за банку варенья и ящик печенья

Успехов! Rob.

Так я как раз и пытаюсь упростить работу! :-) Т.е. не делать MAC самому, а поставить готовую микросхему за пару десятков у.е. Что касается мегафункции, то если за мегафункцию Ethernet MAC нужно выложить 30 000$, а блок PCe уже стоит внутри ПЛИС бесплатно, то выбор очевиден...


Совершенно справедливо. Поэтому в самом первом посте я детально обрисовал требования к системе, и в последующих постах их уточнил. Т.е. система крайне проста: есть устройство, генерирующее поток данных порядка 100 Мбайт в секунду. После съема данных со всех 128 датчиков (это занимает примерно 2 секунды) допустима небольшая пауза (порядка 250-500 мсек). Моя задача состоит в том, чтобы максимально просто организовать передачу этих данных в компьютер по оптоволоконному кабелю (или двум кабелям) с помощью Ethernet. (Ничем иным это, видимо, не сделаешь.) Естественно, что мне совсем не хочется городить в устройстве что-то большое, сложное и дорогое.


Интересная мысль, спасибо! Только я не понял, почему там 10 бит на слово данных? Наисано, что "IEEE 802.3 Gigabit Ethernet Compliant", а что это означает - неясно... Надо будет повнимательнее даташит почитать...


Так я и должен буду формировать :-)

Спасибо за помощь!

P.S. На входе эта микросхема ожидает 8b/10b encoded data, т.е. это, типа, выходной "кусок" Ethernet MAC? Интересно... Может входную часть этого MAC'а будет несложно реализовать?...

Приветствую!



Нет это просто внешний MGT - MAC и PCS\PMA надо будет самому делать. Опять же - всего пара FSM .
Но это в любом случае будет проще чем рулит внешним Ethernet PCIe чипом через встроенный PCIe root-complex

Успехов! Rob.

Здорово! Пожалуйста, поподробнее! Я ведь только что занялся этими вопросами, все больше с USB 2.0 работал, опыта - ноль. Желания понять - хоть отбавляй! :-)

Я уже понял, что такое Ethernet-фрейм. Несложная штука в общем-то. Что в нем понимается под MAC и PCS\PMA? Я думаю, что без проблем смогу сформировать последовательность байт, составляющих этот самый Ethernet-фрейм. Это и получится канал передачи? Мне бы по-проще все это организовать. Не нужно вообще ничего сложного, просто передавать фреймы вовне и все.

Приветствую!


Похвальное стремление!

Почитайте про уровни сетевого стека для начала хот-бы в Wiki. Если в двух словах : MAC формирует фрейм Ethernet на выходе имеет стандартный media independed interface *MII (MII, GMII, RGMII SGMII ) -> PCS кодирует фрейм в соответствии с требованиями физического канала PMA осуществляет синхронизацию/доступ к физ. каналу.
Посмотрите что и как делаю другие http://opencores.org/projects тут в принципе можно найти готовые решения.

Успехов! Rob.

Большое спасибо за помощь! С теорией я уже ознакомился (только пока никак не запомню значение многочисленных сокращений: MGT, MAC, PCS, PMA и т.д.), теперь поизучаю opencores. Надеюсь смогу разобраться.

Спасибо!

Извините, у меня немного отвлеченный вопрос: А зачем тут Езернет?
Какое из достоинств Езернета используется в данной задаче "передать поток 100 МБ/с на 300 м в системе точка-точка"?
Если получается стандартными средствами-то тогда понятно зачем. А если все равно что-то уникальное городить нужно- то, может, и не Езернет применить?

Исходя из скорости потока и расстояния передачи на PC с Виндой, я подумал, что Ethernet - это единственно возможный вариант. Я просто не знаю, какие еще неэкзотические решения тут применимы...

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

Немножко отошел от аппаратной части и занялся программной. Для начала установил Wireshark. Затем установил в компьютер отдельную сетевую плату. Это для того, чтобы промоделировать реальную систему. Скорость на данном этапе мне не важна, поэтому удовольствовался 100 MB. Подключил мой компьютер к другому компьютеру через коммутатор. Оба имеют свои IP, видят друг друга, все OK.

Потом написал простой UDP Echo Server, а к нему соответствующий клиент. Пример взял отсюда: Самоучитель игры на WINSOCK. Запустил. Все красиво, все работает. Решил посмотреть, что там внутри творится. А там - полный кавардак! Постоянно валят какие-то TCP передачи, ARP пакеты и много всякого другого.

Начал размышлять. Понятно, Винда желает быть ко всякой бочке затычкой, все ей неймется, всюду лезет. В общем, нормальная сетевая жизнь. Тогда я подумал: отсоединю-ка я проверочный сегмент от основной сети. Прописал фиксированные IP (как и будет в законченной системе), но не понял, что делать с Default Gateway. Оставил это поле пустым. Для начала посмотрел Wireshark'ом. Вроде все тихо. Запускаю сервер, запускаю клиент - нет передачи! Точнее есть, но с паузой в 7 секунд (видать некий таймаут). Получился какой-то затык... Wireshark показывает какие-то левые запросы (типа: Who is 192.168.1.51 (а это сервер, видать клиент не знает его MAC-адреса) и еще что-то).

Посему вопросы:

1. Как же все-таки правильно сконфигурировать сегмент сети, чтобы он нормально работал?
2. Как сделать так, чтобы каналу передачи было ясно, куда и что посылать? Наверное нужно как-то указать физический MAC-адрес, чтобы почтальон не сомневался?
3. Может быть оставить все как есть? Но ведь тогда сеть будет отвлекаться на что-то лишнее, что "отгрызет" у меня немножко дорогого траффика...

Разъясните, пожалуйста, начинающему, как мне правильно поступить?

Спасибо!

P.S. Гугл обычно рассматривает стандартную Сеть. TCP послал туда, IP по дороге разобрался/собрался, компьютер назначения получил вожделенную информацию. А вот чтобы детально рассмотреть вопрос - этого не видать...

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

Да, я именно об этом и подумал. В общем-то мне именно это и нужно. Просто под рукой кросс-кабеля не нашлось :-) Но я его или найду, или сделаю сам.

А как насчет ARP-пакетов? Они ведь останутся? Ведь, насколько я понял, клиенту MAC-адрес вынь да положь? Спускаться на уровень Ethernet-фреймов или как-то иначе?

Вообще-то, современные сетевые карты умеют менять функции каналов приема/передачи автоматически. Так что можете попробовать соединить компьютеры обычным патч-кордом.


MAC-адрес обычно аппаратно прописан в каждой сетевой карте.


ARP-пакеты в сети закончатся, как только оба клиента узнают MAC-адрес своего партнера.

У меня плата не "молодая", не поддерживает, пробовал.


Да, источника - прописан, но ведь сетевому уровню для Ethernet-фрейма нужен и адрес приемника? Насколько я понял, именно для этого и применяются отдельные запросы.


Они постоянно валят, заразы...

А как вообще организовать связь двух изолированных компьютеров? Нет DHCP, нет роутера - вообще никого больше.

Может, для начала почитать какой-нить букварь по TCP/IP?

А то, эти ваши вопросы.. "они постоянно валят, заразы..."

Да читал я... В "букварях" не описываются тонкости взаимодействия интерфейсов. К тому же, я хотел бы использовать UDP протокол. Он намного "легче" TCP. И я совсем не встречал ситуации соединения двух компьютеров без всей остальной тяжеловесной инфраструктуры. Меня как раз и интересует, как по-проще это сделать. Т.е. без Интернета, без всего остального громоздкого и сложного для понимания. Просто компьютер-компьютер и все.

Приветствую!


Для начала смотрите команды с ничего не значащими именами - route и arp.

При точка-точка паразитного трафика в канале будет немного - изредка ARP - иногда ICMP это если Вы вдруг не туда что-то слать начнете - в общем - мешать не должно.

Успехов! Rob.