Комментарии 24
Интересная статья для общего развития.
Хотелось бы конечно ссылок на нормальные статьи, а не RFC. Штука полезная, не спорю, но читать их архимуторно.
Хотелось бы конечно ссылок на нормальные статьи, а не RFC. Штука полезная, не спорю, но читать их архимуторно.
Если просто читать — согласен, муторно. А вот если требуется описанное реализовать в софте/железе — тут и начинаешь ценить эту дотошность RFC! :)
Вот тут посмотрите Книга бывшего преподавателя, думаю что на большинство вопросов ответы Ва там сможете найти
Не первый год знаком с сетями, но почерпнул много интересного. Реально полезные вещи.
Спасибо.
Спасибо.
Не знал про рванные маски… спасибо
Мои заметки на полях про IPv6 vasilisc.com/ipv6
Сейчас активно изучаю на тестовом стенде по купленной книге.
Мои заметки на полях про IPv6 vasilisc.com/ipv6
Сейчас активно изучаю на тестовом стенде по купленной книге.
>Если 8ой бит выставлен в 1, то адрес multicastПонятие multicast НЕприменимо ко второму уровню. Тут ходят BROADCAST. Мультикасты ходят на третьем (IP) уровне. Но multicast на втором уровне передаются посредством broadcast, это да.
=)
А как же тогда igmp, подписка на группы и прочее?
igmp — это третий уровень. Адрес в igmp — это IP адрес. Точнее IP-milticast.
MAC-адреса работают на втором уровне. Установка 8-го бита в первом октете MAC-адреса в поле DMAC — это BROADCAST.
В противном случае приведите мне пример отличия broadcast от multicast выраженные на втором уровне в MAC-адресе.
MAC-адреса работают на втором уровне. Установка 8-го бита в первом октете MAC-адреса в поле DMAC — это BROADCAST.
В противном случае приведите мне пример отличия broadcast от multicast выраженные на втором уровне в MAC-адресе.
Ну и что, что igmp — третий уровень?
Кадры с broadcast-адресом должны отсылатся всем в подсети, а кадры с multicast-адресом можно тем, кто не учавствует в группе, не отправлять. Это отличие на втором уровне. Да, большинство свичей не умеет определять, кто в какой группе, но некоторые умеют, и этим пользуются.
Кадры с broadcast-адресом должны отсылатся всем в подсети, а кадры с multicast-адресом можно тем, кто не учавствует в группе, не отправлять. Это отличие на втором уровне. Да, большинство свичей не умеет определять, кто в какой группе, но некоторые умеют, и этим пользуются.
Неправда
На этом месте спотыкались люди даже, разбирающиеся в сетях.
Приведу тут ссылку на самый достоверный источник(с) Multicast address
Приведу тут ссылку на самый достоверный источник(с) Multicast address
Ну wikimedia первый раз вижу, так что за достоверный источник не приму.
Тогда уж велкам ту CiscoWiki
Ну чтож, прийдётся согласиться.
Если стоит 8-ой бит первого октета — то это MULTICAST
Если стоят все F — то это BROADCAST
НО!
С точки зрения коммутатора — в чём разница?
И то и другое получат все в данном L2-cегменте.
Я частенько ковыряюсь в дампах сети и просто держу в голове утверждение — «если у пакета есть 8-ой бит — значит это BROADCAST».
В сущности при разборе дампов главное понимать как раз то, кто этот пакет получит. А получат его как раз все участники текущего L2-домена, так что нельзя сказать, что моё утверждение ложно.
Хотя если коммутатор поддерживает igmp, то тогда пакет получат только участники рассылки.
Впрочем в большинстве случаев если вы получили пакет с 8-мым битом, то скорее всего его получили также все в этой сети.
Таким образом рассылается например STP BPDU(только что проверил — DMAC=01:80...), который явно должен рассылаться броадкастом и всем, а не мультикастом и выборочно.
Тогда уж велкам ту CiscoWiki
Ну чтож, прийдётся согласиться.
Если стоит 8-ой бит первого октета — то это MULTICAST
Если стоят все F — то это BROADCAST
НО!
С точки зрения коммутатора — в чём разница?
И то и другое получат все в данном L2-cегменте.
Я частенько ковыряюсь в дампах сети и просто держу в голове утверждение — «если у пакета есть 8-ой бит — значит это BROADCAST».
В сущности при разборе дампов главное понимать как раз то, кто этот пакет получит. А получат его как раз все участники текущего L2-домена, так что нельзя сказать, что моё утверждение ложно.
Хотя если коммутатор поддерживает igmp, то тогда пакет получат только участники рассылки.
Впрочем в большинстве случаев если вы получили пакет с 8-мым битом, то скорее всего его получили также все в этой сети.
Таким образом рассылается например STP BPDU(только что проверил — DMAC=01:80...), который явно должен рассылаться броадкастом и всем, а не мультикастом и выборочно.
Есть 2 вопроса:
1) Почему STP BPDU «который явно должен рассылаться броадкастом и всем» шлётся не на FF:FF:FF:FF:FF:FF?
2) Зачем конечному хосту не совместимому со стандартом 802.1D получать BPDU?
1) Почему STP BPDU «который явно должен рассылаться броадкастом и всем» шлётся не на FF:FF:FF:FF:FF:FF?
2) Зачем конечному хосту не совместимому со стандартом 802.1D получать BPDU?
0)Трафик снимал SPAN-сессией между cisco2950 и cisco2821.
1)Факт не реклама. Понятия не имею почему, но часто сталкивался с тем, что широковещательные пакеты шлются именно с выставленным 8-мым битом, а не на FF:FF:FF:FF:FF:FF.
Собственно поэтому и имел заблуждение на счёт того, что это и есть броадкаст.
Чистый броадкаст как-то редко встречается в природе =)
Ну разве что ARP.
2)Тем не менее с конфигом по умолчанию коммутатор шлёт BPDU на все порты без разбору кто там подключен и это правильно, ибо коммутатор не может знать, что будет подключено к порту(хост или другой свитч), а петли обнаруживать надо в любом случае.
1)Факт не реклама. Понятия не имею почему, но часто сталкивался с тем, что широковещательные пакеты шлются именно с выставленным 8-мым битом, а не на FF:FF:FF:FF:FF:FF.
Собственно поэтому и имел заблуждение на счёт того, что это и есть броадкаст.
Чистый броадкаст как-то редко встречается в природе =)
Ну разве что ARP.
2)Тем не менее с конфигом по умолчанию коммутатор шлёт BPDU на все порты без разбору кто там подключен и это правильно, ибо коммутатор не может знать, что будет подключено к порту(хост или другой свитч), а петли обнаруживать надо в любом случае.
Основной смысл multicast адреса на L2 в том, что даже умные свитчи понимающие IGMP/MLD не будут заглядывать в L3 заголовок для определения типа пакета — оно не нужно ибо всё отражено в MAC-адресе(хоть и не без false-positives). Да и в FDB, насколько я понимаю, хранятся не IP'шники, а MAC'и.
Так же заметьте, что multicast трафик не будет нагружать CPU железки которая его не должна принимать. Сравните вывод
Так же заметьте, что multicast трафик не будет нагружать CPU железки которая его не должна принимать. Сравните вывод
tcpdump и tcpdump -p.
а как же 01-00-5E-xx-xx-xx?
ЕМНИП, RTS/CTS использовалась во всех Wi-Fi, начиная с чистого 802.11 и включая a, b и g.
Автор, а чем ваш лектор аргументировал, что L2 нужно терминировать как можно раньше и уже на access'е держать L3? Просто то было актуально черте когда. Тенденции-то сейчас совершенно обратные, т.к. современное оборудование уже на access'е может фильтровать пакеты чуть ли не до седьмого уровня (а также бродкасты зафильтровать и так далее) и смысла нарезать все на L3-домены нет никакого — можно так «чисто и гладенько» причесать трафик, что он в виде L2 хоть до ядра дойдет и никому ничего плохого не сделает… В итоге — просто и гибко. Заодно и немного деньжат экономим, т.к. L3 чуть повыше ставим.
Слишком много всего нужно учитывать: Broadcast штормы, ARP спуфинг, STP root hijack, VLAN hopping. Это только то что с ходу вспомнилось, на практике я думаю на практике там много больше всего(соответственно ACL'и на свитчах будут гигантские). Так что лучше перестраховаться и давать клиентам L3.
Гм. Ну может где-то, где очень правила хитрые — там да. А при обслуживании массового клиента ничего там гигантского нет — поверьте мне, сам делал. Для половины даже ACL не надо — встроенными средствами коммутаторов режется все, что надо — только «галочку» поставь. У меня L2 сегмент на 3 тыс. человек работал вообще без проблем, бродкастовых штормов и т.п. При том что клиенты — вирус на вирусе и вирусом погоняет. :-) И, например, Билайн в Москве аналогично строит — L3 выделяется только на целый район.
Впрочем, это все провайдинг. В корпоративе, очевидно, несколько иначе, но конкретные аргументы все равно было бы любопытно услушать.
Впрочем, это все провайдинг. В корпоративе, очевидно, несколько иначе, но конкретные аргументы все равно было бы любопытно услушать.
коллеги, кажется почти все из хтого должно быть в памяти всегда, как же вы работали без этого раньше?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
О сетях: всего понемногу