Есть кто на phd конференции с желанием пересечься?

Коллеги тут наткнулся недавно на такой вопрос : Для чего используется HELLO протокол.

Ответ вообще порадовал ) HELLO протокол использует время вместо дистанции для определения оптимального маршрута. Является аналогом RIP

Так вот вопрос это я такое днище что не знаю таких очевидностей ) или собака просто зарыта так глубоко что я недорыл? )

ты днище

http://www.tcpipguide.com/free/t_TheHELLOProtocolHELLO.htm

Коллеги тут наткнулся недавно на такой вопрос : Для чего используется HELLO протокол.

правильный ответ: протокол HELLO не используется

Ну гуглом я тоже воспользовался. И эту ссылку видел )

Но приведите пример других источников где говорится что он не используется )

https://tools.ietf.org/html/rfc891

This document describes the local-net architecture and protocols of the Distributed Computer Network (DCN), a family of local nets based on Internet technology and an implementation of PDP11-based software called the Fuzzball

Если вглядитесь то во множестве ссылок например идет отсылка о том что OSPF использует Hello Protocol

ты когда в последний раз видел живой PDP-11?

OSPF Hello Protocol - это не отдельный протокол, а некая совокупность задач OSPF

а протокол HELLO - это самостоятельный протокол динамической маршрутизации для PDP-11

ты когда в последний раз видел живой PDP-11?

Если почитать RFC 891, то там рассматривается механизм использования HELLO messages, и в принципе Hello process, но не Hello Protocol.

это неправда

Из текста вижу что описывается работа Hello process который используе Hello protcol, а не hello protocol сам.

И тем не менее это не отменяет моего вопроса ) зачем совокупность задач как вы выразились для OSPF и IS-IS называется Hello protocol ) в случае если это должно указывать на протокол который уже не работет.

https://tools.ietf.org/html/rfc2328#page-52

описан процесс, реализующий HELLO Protocol. детали реализации указывают формат сообщений и необходимые функции

При этом в RFC для OSPF v2 так же используется акроним Hello protocol

не мешайте в одну кучу подзадачу "Hello protocol" в OSPF, EIGRP и других протоколах и самостоятельный протокол HELLO

это абсолютно разные сущности, никак не связанные друг с другом

не родственники и даже не однофамильцы

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

не мешайте в одну кучу подзадачу "Hello protocol" в OSPF, EIGRP и других протоколах и самостоятельный протокол HELLO

Вот кроме 2ух приведеных из гугла Вами ссылок, я что то более нигде информации об этом не нашел ) А вы говорите что я прям днище что это настолько примитивная вещь что давно уже надо было знать.....разница ведь же в написании букв )

я ж пошутил про днище

неужели это не очевидно было? ???

протокол абсолютно некрофильский

даже по розовый ссылке посмотрите, что его окружает

GGP и IGRP

все это протоколы классовые

конкретно HELLO не просто классовый протокол, а еще и ограничен сетями класса С

GGP, IGRP и RIPv1 хотя бы с произвольными классовыми сетями могли работать

они аж четыре байта адреса сети передавали

а этот - только три

Зато как быстро

Э - экономия

кстати, я тут наврал. в RFC написано, что можно три байта от любой сети положить

протокол абсолютно некрофильский

Да я верю что Некрофильский ) но как вопрос весьма забавен )) я например до сегодня не знал что существует такой некрофильский протокол в принципе.

а про протоколы GGP и EGP знали?

все это предания старины глубокой

сугубо классовые протоколы, которые вымерли еще в начале 90-х

коллеги, кто нибудь знает - ASA умеет negate cell (как Checkpoint) пример: permit src не-(dst), т.е. разрешить что-то на всё кроме dst??? не знаю как правильно назвать фичу чтобы погуглить по release notes

кстати, я тут наврал. в RFC написано, что можно три байта от любой сети положить

Ну тогда три байта идентифицировали любую сеть

ога

Хорошие были времена, душевные

Всем привет. Кто может наставить на путь истинный? Вопрос такой, просто интересно. Есть например транковый порт, не важно какой вендор. Например транковый порт - гигабитный. На транковом порту 5 виланов. Как будет распределяться скорость на физически гигабитном транке между 5 логически гигабитными виланами? Например, еслу вдруг в одном из виланов кто то внезапно! вспомнил что забыл скачать последний сезон "игры престолов"?

никак

Всем привет. Кто может наставить на путь истинный? Вопрос такой, просто интересно. Есть например транковый порт, не важно какой вендор. Например транковый порт - гигабитный. На транковом порту 5 виланов. Как будет распределяться скорость на физически гигабитном транке между 5 логически гигабитными виланами? Например, еслу вдруг в одном из виланов кто то внезапно! вспомнил что забыл скачать последний сезон "игры престолов"?

что такое 5 гигабитных виланов в данном контексте? vlan - это обычно речь лишь про тэг во фрейме и никак не привязан к скорости

FIFO

что такое 5 гигабитных виланов в данном контексте? vlan - это обычно речь лишь про тэг во фрейме и никак не привязан к скорости

Возможно, я просто запутался.

опасный вопрос, щас днищем начнут обзывать

То есть полоса просто займется тем кто вдруг врубил, например торрент?

свитчи не оперируют понятием "полосы" до тех пор, пока вы их явно не проинструктируете делать это

до тех пор они просто форвардят кадры

приходит на одном порту кадров сто миллионов байт, а на другом 64 - будет форвардиться все вместе

А как в данном случае будут чувствовать себя другие сабинтерейсы на данном порту? Задержки и потери?

субинтерфейсы на свитчах?

я что-то пропустил и это стало законно?

Нет. Напрмер роутер он а стик

ERROR: S client not available

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

И на нем интервиланроутинг

у вас на порту приходят кадры

просто приходят. просто кадры

какие-то с башкой .1Q, какие-то без

они все попадают во входящий буфер

дальше из буфера их что-то разбирает

А как в данном случае будут чувствовать себя другие сабинтерейсы на данном порту? Задержки и потери?

пока хватает физических ресурсов, буферов для пересылки кадров и все потоки не превышают скорости порта - всё будет работать без проблем.

раскладывает по входящим буферам субинтерфейсов

если успевает разложить - все хорошо, если не успевает - входящий буфер железного интерфейса переполняется, кадры теряются по tail drop

пока хватает физических ресурсов, буферов для пересылки кадров и все потоки не превышают скорости порта - всё будет работать без проблем.

В случае если превышают?

если успевает разложить - все хорошо, если не успевает - входящий буфер железного интерфейса переполняется, кадры теряются по tail drop

Устройство их просто дропает? Как это будет выглядеть с точки зрения icmp?

В случае если превышают?

тут стопицот вариантов QoS(разные очереди, буферы, алгоритмы и т.д.), interleaving и прочих странностей. мы вообще ждём эту тему на linkmeup

какой icmp? вы просто не смогли получить кадр

тут стопицот вариантов QoS(разные очереди, буферы, алгоритмы и т.д.), interleaving и прочих странностей. мы вообще ждём эту тему на linkmeup

Нет. Настройка простая. Есть транковый порт и ничего больше

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

какой icmp? вы просто не смогли получить кадр

В таком случае packe loss, так?

да

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

он грустно лег на коврик у двери и сдох

свитч про это ничего не знает

А если делэи в интервилан роутинге? Не хватает буфера?

не понимаю вопрос

Роутер он а стик. Интервилан роутинг. И задердки хаотичные задержки пакетов. 1мс, 60мс,1мс, 500мс и т.д.

500мс - подозрительно

никакой буфер столько не вытянет

если речь про гигабитные скорости

500 мс - где? icmp же зачастую не обрабатывается аппаратно, может где-то CPU загружен.

угу

либо еще может быть такое, что на клиенте логика козлит

просто 500мс на гигабитной скорости это 50 мегабайт

железных буферов на свитчах просто столько не бывает