Комментарии 209
Очень интересно, ждем ответы на вышеуказанные вопросы
На вопрос, похожий на B10 (Может ли адрес 10.0.1.0 быть использован для адреса хоста?) мне на собеседованиях не ответил никто.
А вот всю жизнь мечтал узнать: сколько вольт в витой паре Ethernet? Я подозреваю, что 1-2.
А вот всю жизнь мечтал узнать: сколько вольт в витой паре Ethernet? Я подозреваю, что 1-2.
А я думаю, что 5 :)
Идём в гугл?
Идём в гугл?
Вот здесь написано про 1 вольт
Думаете 5 потому что TTL?
А ничего, что там разностный сигнал используется, а 5В через сто метров может стать чем угодно, учитывая частоту модуляции? А, кстати, на расстоянии 100 м — 5 в относительно чего мерить будем? Земля у каждого может быть своя.
В общем, трансиверы в карточках не просто так стоят, и на проводах там не TTL-напряжения.
А ничего, что там разностный сигнал используется, а 5В через сто метров может стать чем угодно, учитывая частоту модуляции? А, кстати, на расстоянии 100 м — 5 в относительно чего мерить будем? Земля у каждого может быть своя.
В общем, трансиверы в карточках не просто так стоят, и на проводах там не TTL-напряжения.
Какая земля? В стандарте нет земли и в этом его прелесть. А напряжение мерится относительно провода в оболочке такого же цвета.
Глянул осциллографом, на двух верхних картинках 200 мВ на клетку, на последней 1 В на клетку, Ethernet PHY Micrel KSZ8001LI:
До трансформатора (идет обмен):
После трансформатора (идет обмен):
Линковые импульсы до трансформатора (линк не поднят, нет обмена):
До трансформатора (идет обмен):
После трансформатора (идет обмен):
Линковые импульсы до трансформатора (линк не поднят, нет обмена):
дифференциальным щупом смотрели?
У моего осцилла нет диф. входа. и соответствующего щупа. Просто землю щупа подключил к -TX, а сам щуп к +TX. До, и после трансформатора. Длина тут маленькая, так, что даже не на диф. щуп ни каких особых помех ловиться не должно. Осцилл работал от батареек, это для некоторых измерений тоже важно, особенно на дешевых осциллографах с дурацким блоком питания :-)
оффтоп конечно, но дело тут больше не во внешних помехах, а в индуктивности земляного провода осциллографа. Вообще совет — если ВЧ какие то сигналы мерите — снимайте этот провод и подцепляйте землю прямо к контактной площадке на самом щупе — это позволяет увеличить макс измеряемую частоту в 2-4 раза
На вопрос, похожий на B10 (Может ли адрес 10.0.1.0 быть использован для адреса хоста?) мне на собеседованиях не ответил никто.
Может. Банальный пример сеть 10.0.0.0/23
Пардон, промазал.
Вверху картинки с осциллограммами я привел, можете полюбоваться :-)
Круть.
Напомнило историю, которую мне знакомый рассказал.
Его друг звонит провайдеру.
— Девушка, у меня ADSL модем не работает — не выдает сигнал.
— Ой а вы его в розетку включили? А прокси у вас не настроен? А пинг можете сделать? А антивирус недавно не ставили? и т.д.
— ДА Я ГОВОРЮ: МОДЕМ НЕ РАБОТАЕТ — Я К НЕМУ ОСЦИЛЛОГРАФ ПОДКЛЮЧИЛ
Напомнило историю, которую мне знакомый рассказал.
Его друг звонит провайдеру.
— Девушка, у меня ADSL модем не работает — не выдает сигнал.
— Ой а вы его в розетку включили? А прокси у вас не настроен? А пинг можете сделать? А антивирус недавно не ставили? и т.д.
— ДА Я ГОВОРЮ: МОДЕМ НЕ РАБОТАЕТ — Я К НЕМУ ОСЦИЛЛОГРАФ ПОДКЛЮЧИЛ
В8. Смогут ли пинговать друг друга два компьютера в таких условиях
Я не согласен с вашим ответом. Как вы вообще собираетесь назначить компьютеру шлюз 192.168.0.1, если у компьютера адрес в сети 192.168.1.0/24?
Я не согласен с вашим ответом. Как вы вообще собираетесь назначить компьютеру шлюз 192.168.0.1, если у компьютера адрес в сети 192.168.1.0/24?
Стандарты этого не запрещают, вернее, не требуют, чтобы шлюз был в той же сети.
Основное требование, чтобы он был _доступен_.
И я видел такие сети. Работает.
И попробуйте — и Windows, и Linux дают назначить такие шлюзы. Windows, правда, ругнётся.
Основное требование, чтобы он был _доступен_.
И я видел такие сети. Работает.
И попробуйте — и Windows, и Linux дают назначить такие шлюзы. Windows, правда, ругнётся.
Линукс не даст. Например, ip route add a via b не добавит маршрут, если b не доступен непосредственно (т.е. не находится в любой из сетей, в которых находится локальная станция). Что логично.
Если на то пошло, то можно сделать подобное, сделав ip route add 192.168.0.1/32 dev eth0 и потом уже ip route add default via 192.168.0.1 — но это будет работать именно потому, что мы сначала добавили первый из этих маршрутов. Я не удивлюсь, если винда именно так и делает «под капотом». Проверьте таблицу маршрутизации.
Если будете спорить, сначала ответьте на вопрос: зачем нужно задавать маску подсети, и на что вообще она влияет?
Если на то пошло, то можно сделать подобное, сделав ip route add 192.168.0.1/32 dev eth0 и потом уже ip route add default via 192.168.0.1 — но это будет работать именно потому, что мы сначала добавили первый из этих маршрутов. Я не удивлюсь, если винда именно так и делает «под капотом». Проверьте таблицу маршрутизации.
Если будете спорить, сначала ответьте на вопрос: зачем нужно задавать маску подсети, и на что вообще она влияет?
Маршрут добавить не даст, а дефолтным шлюзом поставить даст. Попробуйте же.
> Если будете спорить, сначала ответьте на вопрос: зачем нужно задавать маску подсети, и на что вообще она влияет?
Ответ: чтобы понять, какие пакеты напрямую отправлять, а какие через шлюз )
Но опять же нет требования, чтобы шлюз был в той же сети )
Но опять же нет требования, чтобы шлюз был в той же сети )
Так а на что влияет-то маска? Где можно её потом увидеть?
Спрошу по-другому: как компьютер с помощью маски определяет, какие отправлять локально, а какие через шлюз?
А требование вообще-то есть. Требование звучит «шлюз должен быть доступен непосредственно в локальной сети (link-local)». Кстати, это же правило допускает использование при маршрутизации указание link-local адреса шлюза в качестве умолчания. Т.е. на локальном интерфейсе его вообще не обязательно иметь «белый».
Спрошу по-другому: как компьютер с помощью маски определяет, какие отправлять локально, а какие через шлюз?
А требование вообще-то есть. Требование звучит «шлюз должен быть доступен непосредственно в локальной сети (link-local)». Кстати, это же правило допускает использование при маршрутизации указание link-local адреса шлюза в качестве умолчания. Т.е. на локальном интерфейсе его вообще не обязательно иметь «белый».
Да, но нет требования, чтобы он был в той же сети логически.
Если у вас в ОДИН свич воткнут ваш хост и шлюз, но хост 192.168.1.1/24, а у шлюза адрес 192.168.2.1 (с любой маской), то они «видят» друг друга непосредственно. Попробуйте )
Чтобы проходили пинги именно до шлюза, то нужно, чтобы сеть шлюза включала в себя и адрес хоста.
Т.е. может быть так, что 192.168.1.1/24 — ваш хост, а 192.168.2.1/16 — шлюз. И тогда будут ходить пинги туда-обратно.
Я серьёзно говорю, попробуйте на виртуалках.
В своё время я тоже удивился такой схеме, но она реально работает.
Если у вас в ОДИН свич воткнут ваш хост и шлюз, но хост 192.168.1.1/24, а у шлюза адрес 192.168.2.1 (с любой маской), то они «видят» друг друга непосредственно. Попробуйте )
Чтобы проходили пинги именно до шлюза, то нужно, чтобы сеть шлюза включала в себя и адрес хоста.
Т.е. может быть так, что 192.168.1.1/24 — ваш хост, а 192.168.2.1/16 — шлюз. И тогда будут ходить пинги туда-обратно.
Я серьёзно говорю, попробуйте на виртуалках.
В своё время я тоже удивился такой схеме, но она реально работает.
Я собственно попробовал, ниже посмотрите внимательно. Система не даёт добавить такой маршрут по умолчанию (=указать шлюз).
Информация, где шлюз, должна быть заранее в памяти компьютера. В случае, если «шлюз» указанный принадлежит к другой подсети, это не так — непонятно, как добраться до самого шлюза, например, через какой интерфейс, если их несколько, какой «обратный адрес» подставлять при этом и так далее.
То есть, перед тем, как указывать шлюз, мы должны непременно иметь маршрут до шлюза.
Винда действительно втихую добавляет сначала маршрут до шлюза, а уже потом маршрут по умолчанию через шлюз, поэтому в ней работает. Линукс ничего втихую не делает, но если в нём вручную сделать так же, тоже будет работать.
Попробуйте на виртуалках, посмотрите на таблицы маршрутизации, убедитесь ;) Только смотреть на все — в линуксе их как минимум три (не забудьте ip route show table local)
Информация, где шлюз, должна быть заранее в памяти компьютера. В случае, если «шлюз» указанный принадлежит к другой подсети, это не так — непонятно, как добраться до самого шлюза, например, через какой интерфейс, если их несколько, какой «обратный адрес» подставлять при этом и так далее.
То есть, перед тем, как указывать шлюз, мы должны непременно иметь маршрут до шлюза.
Винда действительно втихую добавляет сначала маршрут до шлюза, а уже потом маршрут по умолчанию через шлюз, поэтому в ней работает. Линукс ничего втихую не делает, но если в нём вручную сделать так же, тоже будет работать.
Попробуйте на виртуалках, посмотрите на таблицы маршрутизации, убедитесь ;) Только смотреть на все — в линуксе их как минимум три (не забудьте ip route show table local)
Про p2p вы совершенно правы. Но у нас сеть /24, как бы, это не похоже на p2p.
Чтоб адреса не терять, можно использовать маски /32. Собственно, /32 адрес можно назначить нескольким интерфейсам сразу, потому, что он не тянет за собой никаких автоматических маршрутов. Так в линуксе и делается «ip unnumbered».
Так что можно не терять, да: ставим 192.0.2.0/32 на первом, 192.0.2.1/32 на втором, маршруты друг на друга через интерфейс (любго типа, можно и eth) — и вуаля, связь есть. Затратили ровно два адреса.
Вот ещё пример: habrahabr.ru/post/189268/#comment_6572820
Чтоб адреса не терять, можно использовать маски /32. Собственно, /32 адрес можно назначить нескольким интерфейсам сразу, потому, что он не тянет за собой никаких автоматических маршрутов. Так в линуксе и делается «ip unnumbered».
Так что можно не терять, да: ставим 192.0.2.0/32 на первом, 192.0.2.1/32 на втором, маршруты друг на друга через интерфейс (любго типа, можно и eth) — и вуаля, связь есть. Затратили ровно два адреса.
Вот ещё пример: habrahabr.ru/post/189268/#comment_6572820
только не «link-local», а «connected» по-моему
stalker merlin # ip route
127.0.0.0/8 via 127.0.0.1 dev lo
192.168.100.0/24 dev virbr0 proto kernel scope link src 192.168.100.1
192.168.168.0/24 dev br0 proto kernel scope link src 192.168.168.4
stalker merlin # ip route add default via 192.168.55.22
RTNETLINK answers: Network is unreachable
Нельзя, как видим.
127.0.0.0/8 via 127.0.0.1 dev lo
192.168.100.0/24 dev virbr0 proto kernel scope link src 192.168.100.1
192.168.168.0/24 dev br0 proto kernel scope link src 192.168.168.4
stalker merlin # ip route add default via 192.168.55.22
RTNETLINK answers: Network is unreachable
Нельзя, как видим.
А если у меня 10 сетевых карт? Он из каждой ARP-запрос в поисках шлюза сделает?
Согласен, по идее хост обнаружив что адрес находится в другой сети, должен переслать пакет шлюзу, и ARP запрос делается к шлюзу, а не к адресу из другой сети
Приглядитесь к адресации на схеме. Они друг у друга шлюзами назначены.
был невнимателен. тогда, действительно могут пинговаться, хотя забавно получается.
Как компьютер ПК1 должен добираться до 192.168.0.1?
1. Смотрим, не локальный ли адрес это. Нет, не локальный.
2. Смотрим, нет находится ли он в любой из локальных сетей (здесь 192.168.1.0/24). Нет, не находится.
3. Ищем шлюз и делаем ARP-запрос к нему. А через какой интерфейс? Оп-па. Где искать 192.168.0.1? Мы не знаем.
Скажете, что «раз указали в настройках сетевухи 1, значит через неё и искать». Хорошо. Это эквивалентно маршруту «192.168.0.1/32 via сетевуха1», что, собственно, и сделает винда.
Т.е. приведённая в примере конфиуграция, на самом деле, устроена так:
ПК1: 192.168.1.1/32, 192.168.0.1/32 via e0,
ПК2: 192.168.0.1/32, 192.168.1.1/32 via e0.
Т.е. у нас есть два компа и локальные маршруты «непосредственно» друг до друга, хоть оно и в разных подсетях. Конечно, будет пинговаться.
1. Смотрим, не локальный ли адрес это. Нет, не локальный.
2. Смотрим, нет находится ли он в любой из локальных сетей (здесь 192.168.1.0/24). Нет, не находится.
3. Ищем шлюз и делаем ARP-запрос к нему. А через какой интерфейс? Оп-па. Где искать 192.168.0.1? Мы не знаем.
Скажете, что «раз указали в настройках сетевухи 1, значит через неё и искать». Хорошо. Это эквивалентно маршруту «192.168.0.1/32 via сетевуха1», что, собственно, и сделает винда.
Т.е. приведённая в примере конфиуграция, на самом деле, устроена так:
ПК1: 192.168.1.1/32, 192.168.0.1/32 via e0,
ПК2: 192.168.0.1/32, 192.168.1.1/32 via e0.
Т.е. у нас есть два компа и локальные маршруты «непосредственно» друг до друга, хоть оно и в разных подсетях. Конечно, будет пинговаться.
Взял я два ноутбука с дефолтной w7, настроил адреса-шлюзы как сказано (к слову, шлюзы дает настроить, просто спрашивает — вы уверены?), отключил Windows Firewall. Компы сами себя пингают, друг друга — нет. На всякий случай включил через свитч, взял третий ноут и стал давать ему адрес сначала 192.168.1.2, потом 192.168.0.2. В своей подсети все друг друга пингают, через границу подсети — нет. Дорогие ученые, что я делаю не так? (к слову, изначально считал что пингать не будут).
Таблицы маршрутизации покажите
рраз:
C:\Users\IPA_user>route print
===========================================================================
Interface List
14...00 21 86 c9 8a 68 ......Bluetooth Device (Personal Area Network)
11...00 23 7d 97 37 a1 ......Intel(R) 82567LM Gigabit Network Connection
1...........................Software Loopback Interface 1
18...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
15...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
17...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #3
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.0.1 192.168.1.1 266
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
192.168.1.0 255.255.255.0 On-link 192.168.1.1 266
192.168.1.1 255.255.255.255 On-link 192.168.1.1 266
192.168.1.255 255.255.255.255 On-link 192.168.1.1 266
224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 192.168.1.1 266
255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
255.255.255.255 255.255.255.255 On-link 192.168.1.1 266
===========================================================================
Persistent Routes:
Network Address Netmask Gateway Address Metric
0.0.0.0 0.0.0.0 192.168.0.1 Default
===========================================================================
IPv6 Route Table
===========================================================================
Active Routes:
If Metric Network Destination Gateway
1 306 ::1/128 On-link
1 306 ff00::/8 On-link
===========================================================================
Persistent Routes:
None
C:\Users\IPA_user>ipconfig
Windows IP Configuration
Ethernet adapter Bluetooth Network Connection:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . :
IPv4 Address. . . . . . . . . . . : 192.168.1.1
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.0.1
Tunnel adapter isatap.{78B030C5-2A81-468F-AD8B-9EB09BD2B7BF}:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Tunnel adapter Teredo Tunneling Pseudo-Interface:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Tunnel adapter isatap.{B97B1C3A-CBDC-446C-8BF5-C37A12FC954C}:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
два:
C:\Users\nkuznetsov>route print
===========================================================================
Список интерфейсов
14...08 3e 8e 98 b2 d2 ......Bluetooth Personal Area Network
11...10 60 4b 4a fa 7c ......Intel(R) 82579V Gigabit Network Connection
1...........................Software Loopback Interface 1
18...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
20...00 00 00 00 00 00 00 e0 Адаптер Microsoft ISATAP #2
===========================================================================
IPv4 таблица маршрута
===========================================================================
Активные маршруты:
Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрика
0.0.0.0 0.0.0.0 192.168.1.1 192.168.0.1 266
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
192.168.0.0 255.255.255.0 On-link 192.168.0.1 266
192.168.0.1 255.255.255.255 On-link 192.168.0.1 266
192.168.0.255 255.255.255.255 On-link 192.168.0.1 266
224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 192.168.0.1 266
255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
255.255.255.255 255.255.255.255 On-link 192.168.0.1 266
===========================================================================
Постоянные маршруты:
Сетевой адрес Маска Адрес шлюза Метрика
0.0.0.0 0.0.0.0 192.168.1.1 По умолчанию
===========================================================================
IPv6 таблица маршрута
===========================================================================
Активные маршруты:
Метрика Сетевой адрес Шлюз
1 306 ::1/128 On-link
1 306 ff00::/8 On-link
===========================================================================
Постоянные маршруты:
Отсутствует
C:\Users\nkuznetsov>ipconfig
Настройка протокола IP для Windows
Ethernet adapter Подключение по локальной сети 2:
Состояние среды. . . . . . . . : Среда передачи недоступна.
DNS-суффикс подключения . . . . . :
Ethernet adapter Подключение по локальной сети:
DNS-суффикс подключения . . . . . :
IPv4-адрес. . . . . . . . . . . . : 192.168.0.1
Маска подсети . . . . . . . . . . : 255.255.255.0
Основной шлюз. . . . . . . . . : 192.168.1.1
Туннельный адаптер Teredo Tunneling Pseudo-Interface:
Состояние среды. . . . . . . . : Среда передачи недоступна.
DNS-суффикс подключения . . . . . :
Туннельный адаптер isatap.{DB3EB7F0-3F16-4AF2-B4CD-DB4E75948DAF}:
Состояние среды. . . . . . . . : Среда передачи недоступна.
DNS-суффикс подключения . . . . . :
arp -a еще до кучи
пришлось превозмочь лень и сделать две виртуалки на win7, тема работает
а у меня — нет. где правда?
а маршруты-то у вас есть? Мне теперь тоже интересно, не делать же виртуалки, а то вдруг не заработает
маршрутов нет, да они и не нужны, логика следующая: система(192,168,1,1) видит, что нужно пингануть удаленный адрес (192,168,0,1), ищет шлюз с помощью arp запроса, находит, и посылает пакет в шлюз (192,168,0,1), шлюз(192,168,0,1) и по своместительству адресат, видит пакет и понимает что пакет адресован именно ему, собирается ответить, но так как ответ нужно отправить удаленному адресу (192,168,1,1), отсылает пакет шлюзу(192,168,1,1), который по совместительству является получателем пакета…
вы всё-таки покажите таблицы маршрутизации-то
Список интерфейсов
15...00 15 5d a7 ea 35 ......Адаптер магистральной сети виртуальной машины (Май
крософт) #3
1...........................Software Loopback Interface 1
12...00 00 00 00 00 00 00 e0 Адаптер Microsoft ISATAP
14...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
===========================================================================
IPv4 таблица маршрута
===========================================================================
Активные маршруты:
Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрика
0.0.0.0 0.0.0.0 192.168.0.1 192.168.1.1 261
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
192.168.1.0 255.255.255.0 On-link 192.168.1.1 261
192.168.1.1 255.255.255.255 On-link 192.168.1.1 261
192.168.1.255 255.255.255.255 On-link 192.168.1.1 261
224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 192.168.1.1 261
255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
255.255.255.255 255.255.255.255 On-link 192.168.1.1 261
===========================================================================
Постоянные маршруты:
Сетевой адрес Маска Адрес шлюза Метрика
0.0.0.0 0.0.0.0 192.168.0.1 По умолчанию
===========================================================================
IPv6 таблица маршрута
===========================================================================
Активные маршруты:
Метрика Сетевой адрес Шлюз
1 306 ::1/128 On-link
15 261 fe80::/64 On-link
15 261 fe80::1986:d248:1d9a:a469/128
On-link
1 306 ff00::/8 On-link
15 261 ff00::/8 On-link
===========================================================================
Постоянные маршруты:
Отсутствует
и
Список интерфейсов
11...00 15 5d a7 ea 39 ......Адаптер магистральной сети виртуальной машины (Май
крософт)
1...........................Software Loopback Interface 1
12...00 00 00 00 00 00 00 e0 Адаптер Microsoft ISATAP
13...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
===========================================================================
IPv4 таблица маршрута
===========================================================================
Активные маршруты:
Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрика
0.0.0.0 0.0.0.0 192.168.1.1 192.168.0.1 261
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
192.168.0.0 255.255.255.0 On-link 192.168.0.1 261
192.168.0.1 255.255.255.255 On-link 192.168.0.1 261
192.168.0.255 255.255.255.255 On-link 192.168.0.1 261
224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 192.168.0.1 261
255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
255.255.255.255 255.255.255.255 On-link 192.168.0.1 261
===========================================================================
Постоянные маршруты:
Сетевой адрес Маска Адрес шлюза Метрика
0.0.0.0 0.0.0.0 192.168.1.1 По умолчанию
===========================================================================
IPv6 таблица маршрута
===========================================================================
Активные маршруты:
Метрика Сетевой адрес Шлюз
1 306 ::1/128 On-link
1 306 ff00::/8 On-link
===========================================================================
Постоянные маршруты:
Отсутствует
Логика не такая. Если видно, что шлюз не в одной подсети с интерфейсом (не в connected-сети, в терминологии cisco) то будет выполнен recursive route lookup — то есть будут искать в таблице маршрутизации маршрут для достижения шлюза. и только на том шаге где будет найен next hop (именно ip-next-hop) в пределах одной подсети с интерфейсом — только тогда будет отправлен arp на разрешение адреса именно next-hop, а не шлюза. у меня изначально была претензия к вашей и автора логике.
Да легко, гуглите по слову unnumbered. Шлюз не обязан быть в той же подсети что и адрес, есть исключения.
Шлюз не должен быть в той же подсети. Там вообще может не быть подсети. Но вот маршрут до шлюза должен быть до того, как мы назначим шлюз.
Маршрут само собой, но вопрос стоит смогут ли — да смогут.
Объяснение-то неправильное, почему смогут. Вот правильное: habrahabr.ru/post/189268/#comment_6572820
IP адрес шлюза нужен ровно по одной причине: чтобы знать, куда слать arp запрос в поисках нужного мака. Технически, адрес шлюза может быть совершенно произвольным.
Ага. Но в терминах настройки протокола IP — третьего уровня — негде указывать MACи. Их вообще может не быть, мало ли, какой там канальный уровень. Может mGRE, тогда L2-адресами для этого интерфейса тоже будут IP-адреса :)
Поэтому нужен именно адрес шлюза третьего уровня, ip.
Поэтому нужен именно адрес шлюза третьего уровня, ip.
Ну в случае mGRE, положим, про винду вообще забываем :)
В случае ethernet можно было бы и мак указывать вместо IP адреса. И оно бы работало. Но с кучей недостатков от «сложнее запомнить, легче ошибиться» до «смена железки, играющей роль шлюза, превращается в адскую работу по перенастройке всего и вся».
В случае ethernet можно было бы и мак указывать вместо IP адреса. И оно бы работало. Но с кучей недостатков от «сложнее запомнить, легче ошибиться» до «смена железки, играющей роль шлюза, превращается в адскую работу по перенастройке всего и вся».
Не, не соглашусь
То, что для маршрутизации достаточно l2-адреса шлюза, согласен. А вот что его можно было бы указывать — нет. Мы же ip настраиваем, должны оставаться в терминах l3.
То, что для маршрутизации достаточно l2-адреса шлюза, согласен. А вот что его можно было бы указывать — нет. Мы же ip настраиваем, должны оставаться в терминах l3.
В рамках имеющегося диалогового окна «свойства IPv4» — само собой так делать нельзя. Да и в статических маршрутах — тоже было бы неправильно. Но условно: в свойствах IPv4 галка «использовать как основной шлюз» (по аналогии с p2p интерфейсами), а где-то отдельно в настройках интерфейса мак соседа, через которого идти. Но да, это был бы ужас.
Шлюз в принципе может находится и в другой подсети, inarp запрос в таком случае ничего не отрезолвит. Продолжая Вашу аналогию — зачем указывать и мак адрес узла приема? Можно просто ссыпать пакеты в point-to-point интерфейс, сосед сам разберется куда пакет отправлять дальше.
$ ip route
…
default dev ppp1 scope link metric 2000
…
Собственно, так и есть, указан интерфейс, а сосед сам разберётся ;)
…
default dev ppp1 scope link metric 2000
…
Собственно, так и есть, указан интерфейс, а сосед сам разберётся ;)
Можно просто ссыпать пакеты в point-to-point интерфейс
Для point-to-point интерфейсов так и происходит.
Но ethernet категорически не является point-to-point интерфейсом. Даже если он соединяет два хоста.
Но технически можно слать пакеты на FF:FF:FF:FF:FF:FF. Суть не изменится, обработка произойдет. В случае ровно двух хостов на сегмент особой разницы не будет. Просто есть некоторые стандарты, которые лучше соблюдать.
прикольная идея, что-то я как-то не задумывался об испоьзовании ethernet broadcast в такой ситуации
point-to-point — имеется в виду «Ethernet соединение между хостами работающие в полнодуплексном режиме.»
В случае двух хостов можно и не указывать dg. Но звучит эта фраза не про сегмент из двух компов.
IP адрес шлюза нужен ровно по одной причине: чтобы знать, куда слать arp запрос в поисках нужного мака.
В случае двух хостов можно и не указывать dg. Но звучит эта фраза не про сегмент из двух компов.
C:\>ipconfig
Настройка протокола IP для Windows
Подключение по локальной сети — Ethernet адаптер:
DNS-суффикс этого подключения..:…
IP-адрес............: 10.16.1.217
Маска подсети..........: 255.255.255.224
Основной шлюз..........: 10.16.1.193
10:40:05.344028 arp who-has 10.16.1.217 (00:0c:29:a0:99:f8) tell 10.16.2.1
10:40:05.344043 arp reply 10.16.1.217 is-at 00:0c:29:a0:99:f8
Линукс
10:47:42.340969 ARP, Request who-has 192.168.10.1 (00:0c:29:90:4d:6a) tell 10.16.2.1, length 28
10:47:42.352337 ARP, Reply 192.168.10.1 is-at 00:0c:29:90:4d:6a, length 46
Арп запрос в одном л2 сегменте, но для разных л3 сегментов нормально обрабатывается и виндой и никсом.
Настройка протокола IP для Windows
Подключение по локальной сети — Ethernet адаптер:
DNS-суффикс этого подключения..:…
IP-адрес............: 10.16.1.217
Маска подсети..........: 255.255.255.224
Основной шлюз..........: 10.16.1.193
10:40:05.344028 arp who-has 10.16.1.217 (00:0c:29:a0:99:f8) tell 10.16.2.1
10:40:05.344043 arp reply 10.16.1.217 is-at 00:0c:29:a0:99:f8
Линукс
10:47:42.340969 ARP, Request who-has 192.168.10.1 (00:0c:29:90:4d:6a) tell 10.16.2.1, length 28
10:47:42.352337 ARP, Reply 192.168.10.1 is-at 00:0c:29:90:4d:6a, length 46
Арп запрос в одном л2 сегменте, но для разных л3 сегментов нормально обрабатывается и виндой и никсом.
Ну в защиту автора — речь шла об абстрактных компьютерах, а не каких-то определённых системах. Если написать свой сетевой стек — смогут и вроде бы не нарушат никаких стандартов (тут не уверен). Признаюсь, однажды я так и сделал — работало.
Можно поиграть с маской, и получить шлюз _кажущийся_ из другой подсети.
Задавать эти вопросы сисадминам на собеседовании?
(я, конечно, не сисадмин, но ответил только на вопрос B8)
(я, конечно, не сисадмин, но ответил только на вопрос B8)
В11 про обратные маски — я ИНТУИТИВНО когда-то просёк фишку и использовал её (маску с дыркой), но думал, что работает из-за особенностей реализации, а вообще-то не должно было.
Помню, мы лет 10 назад с друзьями выставляли в Win98 маску 255.255.255.100 для дворовой сети, потому что кто-то сказал, что для 100 мегабит последний октет должен быть 100. Вполне проглатывала и оно даже работало.
Потому что, насколько я помню, на какой-то момент времени к маске сети не было требования непрерывности битов. И циски когда-то такое поддерживали. Ну и если задуматься — никаких особых проблем тут нет. Ну кроме проблемы подвешивания за яйца того, кто начнет использовать прерывистые маски в продакшне, так как сопровождать это будет решительно невозможно.
это кстати тоже хороший каверзный вопрос: чем отличается задание маски в виде битов и cidr? хотя он эквивалентен заданному в топике.
Ну положим CIDR — это скорее название когда-то диковинной концепции, а формат маски — частность.
я к тому, что в формате cidr никак не задашь «маску с дырками».
Вы про "/24" и тому подобное? Ага. Но это просто формат записи, появившийся далеко не сразу, и такой формат для IPv4 поддерживается вовсе не везде.
Что-то вроде access-list 100 permit tcp any 10.23.45.67 0.0.122.0
да-да, что-то вроде этого
в 2006 году я маленький и глупый, не знал, как работает интернет, а ещё я подключил ADSL-интернет от провайдера «ВоронежСвязьИнформ», когда он ещё не был куплен центртелекомом, который был потом куплен ростелекомом. Так вот, у них был вебинтерфейс для задания правил фильтрации ip ДО попадания на пользовательское оборудование; если я правильно помнимаю, правила применялись на BRASе. Беспрецендентная штука, на самом деле. BRASы были циски, правила были практически в чистом виде их ACL.
Так вот, безлимитного интернета тогда не было, интернет был дорогой (порядка 1.8р/мегабайт) а вот локальные ресурсы у них были безлимитные. В тех подсетях, трафик из которых был бесплатный, однако, были хосты-исключения с платным трафиком. И наоборот, в интернете была пара адресов, трафик с которых был бесплатным.
Люди так и делали — обрезали этим фильтром себе весь платный трафик, чтоб платить абонентку, качать с локального торрента и в ус не дуть. На это требовалось порядка десяти правил.
И тут грянул гром. Всё начало глючить. Например, мне как-то насчиталось 2.5 Гб из интернета, хотя я физически не был способен столько накачать за такое время (adsl-канал не позволял). Ну, ясное дело, левый трафик обнуляли. Расследование показало, что на BRASах от безумного количества правил в фильтрах банально кончалась ОЗУ и им срывало башку. Фильтры переделали — теперь стало можно сделать фильтр из не более, чем шести правил.
Я горд тем, что я был именно тем человеком, который тогда уложился в эти шесть правил, полностью сохранил доступ ко всем беспланым ресурсам и запретил все платные. Говорят, даже техподдержка ссылалась на мою домашнюю страничку, где я расписал эти правила, как и почему. (Там были подробные объяснения к каждому правилу… где-то есть резервная копия той странички.)
В одном из этих шести правил была обратная маска вида 0.0.0.8 чтоб захватить два платных хоста — 80.82.32.19 и .27, т.е. с дыркой (в другом была обратная маска 0.0.0.1 — платными были два соседних хоста, 80.82.32.10 и .11). Несколько сотрудников провайдера говорили мне, что такая маска — неправильная, вроде как и работать не должно, однако им было крыть нечем — оно работало. Объяснение на моей странице таким и было — мол, маска неправильная, но работает видимо вследствие особенностей реализации обратных масок в маршрутизаторах Cisco.
(Если я не ошибаюсь, OlegD имеет ко всему этому некоторое отношение. Тогда он, возможно, уточнит моменты, в которых я ошибаюсь.)
Собственно, до сих пор я и не знаю, почему работало, однако объяснение из статьи вполне меня удовлетворяет ;)
в 2006 году я маленький и глупый, не знал, как работает интернет, а ещё я подключил ADSL-интернет от провайдера «ВоронежСвязьИнформ», когда он ещё не был куплен центртелекомом, который был потом куплен ростелекомом. Так вот, у них был вебинтерфейс для задания правил фильтрации ip ДО попадания на пользовательское оборудование; если я правильно помнимаю, правила применялись на BRASе. Беспрецендентная штука, на самом деле. BRASы были циски, правила были практически в чистом виде их ACL.
Так вот, безлимитного интернета тогда не было, интернет был дорогой (порядка 1.8р/мегабайт) а вот локальные ресурсы у них были безлимитные. В тех подсетях, трафик из которых был бесплатный, однако, были хосты-исключения с платным трафиком. И наоборот, в интернете была пара адресов, трафик с которых был бесплатным.
Люди так и делали — обрезали этим фильтром себе весь платный трафик, чтоб платить абонентку, качать с локального торрента и в ус не дуть. На это требовалось порядка десяти правил.
И тут грянул гром. Всё начало глючить. Например, мне как-то насчиталось 2.5 Гб из интернета, хотя я физически не был способен столько накачать за такое время (adsl-канал не позволял). Ну, ясное дело, левый трафик обнуляли. Расследование показало, что на BRASах от безумного количества правил в фильтрах банально кончалась ОЗУ и им срывало башку. Фильтры переделали — теперь стало можно сделать фильтр из не более, чем шести правил.
Я горд тем, что я был именно тем человеком, который тогда уложился в эти шесть правил, полностью сохранил доступ ко всем беспланым ресурсам и запретил все платные. Говорят, даже техподдержка ссылалась на мою домашнюю страничку, где я расписал эти правила, как и почему. (Там были подробные объяснения к каждому правилу… где-то есть резервная копия той странички.)
В одном из этих шести правил была обратная маска вида 0.0.0.8 чтоб захватить два платных хоста — 80.82.32.19 и .27, т.е. с дыркой (в другом была обратная маска 0.0.0.1 — платными были два соседних хоста, 80.82.32.10 и .11). Несколько сотрудников провайдера говорили мне, что такая маска — неправильная, вроде как и работать не должно, однако им было крыть нечем — оно работало. Объяснение на моей странице таким и было — мол, маска неправильная, но работает видимо вследствие особенностей реализации обратных масок в маршрутизаторах Cisco.
(Если я не ошибаюсь, OlegD имеет ко всему этому некоторое отношение. Тогда он, возможно, уточнит моменты, в которых я ошибаюсь.)
Собственно, до сих пор я и не знаю, почему работало, однако объяснение из статьи вполне меня удовлетворяет ;)
Ну, вообще я с уверенностью не могу сказать чем маска подсети отличается от обратной маски (кроме инверсии). Из того, что точно знаю — маска подсети никогда не может иметь разрывов, а wildcard mask — может, так еще Одом писал. НО! В обратной маске на последних иосах в ACL можно делать разрывы и все работает, но при записи разорванной маски в протокол маршрутизации иос ругается и отвергает команду.
То есть access-list 100 permit tcp any 10.23.45.67 0.0.122.0 сработает, а
router o 1
net 10.23.45.67 0.0.122.0 a 1 уже не заработает.
Причем такое поведение ACL это фича, одно из доп. заданий на 6 студенческой олимпиаде по cisco было ориентированно как раз на написание такой маски.
То есть access-list 100 permit tcp any 10.23.45.67 0.0.122.0 сработает, а
router o 1
net 10.23.45.67 0.0.122.0 a 1 уже не заработает.
Причем такое поведение ACL это фича, одно из доп. заданий на 6 студенческой олимпиаде по cisco было ориентированно как раз на написание такой маски.
я с уверенностью не могу сказать чем маска подсети отличается от обратной маски
Опять же, различие крайне простое. Маска сети определяет сеть. Инверсная маска определяет хост. Т.е. просто битовая операция с всплывшим откуда-либо адресом (пример — из проходящего мимо пакета) и проверка результата. Инверсная маска никогда и нигде не определяет сеть.
Есть, кстати, охренительно элегантный способ считать близкие к идеальным инверсные маски для заданных диапазонов адресов с целью минимизации числа правил.
blog.ine.com/2010/11/25/performing-access-list-computation-route-summarization-acl-manager/
Маска сети определяет сеть. Инверсная маска определяет хост
Вот две команды.
router o 1
net 10.23.45.67 255.255.0.0 a 1
ip route 10.23.45.67 0.0.255.255 192.168.45.1
Какая из команд определяет хост?
>ip route 10.23.45.67 0.0.255.255 192.168.45.1
И что, вот прям такая команда отработает? Мне что-то кажется, что вас пошлют.
И что, вот прям такая команда отработает? Мне что-то кажется, что вас пошлют.
Как же вы такого не знаете? :)
В OSPF используется инверсная маска вообще-то. Она определяет один конкретный адрес — адрес интерфейса, который будем анонсировать. Можете при случае поиграться с маской, поймете.
Вот в BGP сеть задается командой network 10.23.0.0 mask 255.255.0.0. Это — именно префикс, а не хост. Он не обязан принадлежать локальному интерфейсу.
В ip route тоже определяется сеть, потому маска прямая.
В OSPF используется инверсная маска вообще-то. Она определяет один конкретный адрес — адрес интерфейса, который будем анонсировать. Можете при случае поиграться с маской, поймете.
Вот в BGP сеть задается командой network 10.23.0.0 mask 255.255.0.0. Это — именно префикс, а не хост. Он не обязан принадлежать локальному интерфейсу.
В ip route тоже определяется сеть, потому маска прямая.
В1 — Некоторые товарищи не загоняются на чередование пар — обжимают подряд.
А пытливые просто читают стандарт TIA/EIA-568B
А пытливые просто читают стандарт TIA/EIA-568B
На коротких расстояниях оно даже будет работать. Но потом наводки быстро убивают сигнал.
Да ладно? У нас больше 15 тысяч клиентов на двухпарнике подключены, несколько тысяч на многопарнике, никакие наводки ничего не убивают на расстояниях до 100м, а все потому, что по витой паре идет дифференциальный сигнал по каждой из паре.
Мой комментарий был про обжимку с произвольным чередованием цветов, без разделения, что 1 и 2 — один цвет, а 3 и 6 — другой.
Можно же воткнуть провода, что 3 и 4 будут зелёные, а 5 и 6 — синие, и обжать. И на коротких расстояниях оно будет работать.
Все 8 проводов в витой паре используются, если мне не изменяет память, начиная с 10G. А 100М и 1G работают на 2 парах, так и должно быть.
Можно же воткнуть провода, что 3 и 4 будут зелёные, а 5 и 6 — синие, и обжать. И на коротких расстояниях оно будет работать.
Все 8 проводов в витой паре используются, если мне не изменяет память, начиная с 10G. А 100М и 1G работают на 2 парах, так и должно быть.
Разные пары имеют разный шаг скрутки. Никогда не путайте пары. Особенно это сказывается на стандартах, оканчивающихся на T. Вроде, 100 Base-T, 1000 Base-T. На практике сам сталкивался, когда и линки обрывались, и сигнал шёл как черепаха и вообще коннекта не было.
В стандартах, оканчивающихся на T, эта буква означает twisted — витая пара.
В стандартах, не оканчивающихся на T, сложно перепутать пары — там совсем другой тип кабеля)
В стандартах, не оканчивающихся на T, сложно перепутать пары — там совсем другой тип кабеля)
пары между собой путать можно, нет общего стандарта по выбору пар для многопарников, важно лишь то, чтобы TX жилы скурчены вместе, и RX между собой тоже вместе.
ну так если «подряд обжимать», то как раз они будут разделены
Вы что не знаете. что производителя для улучшения частотных характеристик и межпарных наводок испоьзуют разный шаг скрутки пар.
используя не те пары вы ухучшаете данные характеристики и отсюда соответствующие проблемы. вплоть до обрыва линка. И поверьте, всё проверено практикой, особенно касающиеся кабелей noname.
используя не те пары вы ухучшаете данные характеристики и отсюда соответствующие проблемы. вплоть до обрыва линка. И поверьте, всё проверено практикой, особенно касающиеся кабелей noname.
Правда? А если концы кабеля местами поменять, что, будут обрывы линка?
А в стандарте 1000base-T все четыре пары используются совершенно одинаково — дуплекс на 250mbit/s каждая, с подавлением эха. Т.е. им по идее хорошо бы иметь идентичные электрические характеристики. А тут разный шаг скрутки, понимаешь.
Шаг различается — но нужно это только для того, чтобы crosstalk между парами был меньше. Всё. В остальном пары (должны быть) идентичны и без разницы, какую куда. Важно только, чтобы пары не разделялись.
А в стандарте 1000base-T все четыре пары используются совершенно одинаково — дуплекс на 250mbit/s каждая, с подавлением эха. Т.е. им по идее хорошо бы иметь идентичные электрические характеристики. А тут разный шаг скрутки, понимаешь.
Шаг различается — но нужно это только для того, чтобы crosstalk между парами был меньше. Всё. В остальном пары (должны быть) идентичны и без разницы, какую куда. Важно только, чтобы пары не разделялись.
я тихо вам оставлю ссылки для изучения, если мне не верите
forum.nag.ru/forum/index.php?showtopic=19554
forum.ixbt.com/topic.cgi?id=14:12168-5
forum.nag.ru/forum/index.php?showtopic=19554
forum.ixbt.com/topic.cgi?id=14:12168-5
это вы сейчас про многопарник или про витую пару 6ой категории? Не путайте одно округлое с другим продолговатым.
Это касается любой пары. Более того, чем выше несущая, тем более усугубляется проблемы дорастая до того, что 6 категорию рядом с пятой лучше не класть(появляются уже межкабельные наводки).
www.ecolan.ru/imp_info/introduction/mnav/
www.ecolan.ru/imp_info/introduction/mnav/
не вижу катастрофы, дифференциальный метод передачи сигнала решает проблемы с этими маломощными наводками.
Это снижает отношение сигнал\шум.
нет проблем в выделении этого шума и его ликвидации при восстановлении сигнала, шум будет всегда, поэтому никто не заметит разницы для 100Base-T, а для 1000Base уже используется другая категория кабеля.Так что это не более чем позолоченные разъемы у HiFi акустики с обедненной медью.
Не. Вы не правы. Шумит всё-даже квантовые усилители при температуре в 4 кельвина. Соответственно, вы никогда не сможете улучшуть соотношения сигнал\шум больше того значения, в котором виноваты шумы усилителя.
Для 1000 Base-T пойдёт и категория 5.e сертифицированная по стандарту ANSI/TIA/EIA-568-B.2.
Для шестой категории применяют уже 1000-base-tx. Для 5.e 1000-base-t.
Было в моей практике и такое, когда из-за неправильного обжатия линк черепашкой становился.
А про обеднённую медь-это только для сверхвысококачественного сигнала, которого в быту почти не получить.
Для 1000 Base-T пойдёт и категория 5.e сертифицированная по стандарту ANSI/TIA/EIA-568-B.2.
Для шестой категории применяют уже 1000-base-tx. Для 5.e 1000-base-t.
Было в моей практике и такое, когда из-за неправильного обжатия линк черепашкой становился.
А про обеднённую медь-это только для сверхвысококачественного сигнала, которого в быту почти не получить.
в моей практике в двух провайдерах на протяжении более 6 лет подключали по многопарнику как Бог на душу положит, брали любые две пары, в итоге никакого криминала, у всех все работает, расстояния были до 100м + использовался кросс. Да и в глаза не видел от производителя вообще каких либо рекомендаций по многопарникам.
Обородывание-обородыванию рознь.
Кабель-кабелю рознь.
Производитель-производителю рознь.
Стандарт-стандарту рознь.
И какие рекомендации могут быть, если чёрным по белому написан стандарт, в КОТОРОМ чётко и ясно указана расцветовка и т.п. А также указан гост по СКС. Всё расчитано по ним. А всё что выходит из пределов стандартов и гостов, тут как говорится «как получится».
Я уже не мало набегался по кабинетам, из-за зависаний свичей, которые между собой были соеденены без кросу.
Кабель-кабелю рознь.
Производитель-производителю рознь.
Стандарт-стандарту рознь.
И какие рекомендации могут быть, если чёрным по белому написан стандарт, в КОТОРОМ чётко и ясно указана расцветовка и т.п. А также указан гост по СКС. Всё расчитано по ним. А всё что выходит из пределов стандартов и гостов, тут как говорится «как получится».
Я уже не мало набегался по кабинетам, из-за зависаний свичей, которые между собой были соеденены без кросу.
На 10Mb/s у меня как-то завелась сеть, в которой мотнажник обжал в коннекторе по порядку сперва все цветные жилы, потом — все полосатые, потому что ну так красивее же :)
Вообще Ethernet-classic поразительно живучая штука.
Вообще Ethernet-classic поразительно живучая штука.
В B12 ping не работал бы даже если в левом сегменте были бы адреса не 169.254.X.X, т.к. на 10.0.0.2 в соответствии со схемой не настроено ни шлюза, ни каких-то маршрутов вовне.
В9 — стоит добавить, что directed broadcast запрещён чуть менее чем везде.
В12 — а как вам вот такой трейс:
В14 — на спутниковых линках это заметно совсем хорошо, если вдруг попадается нод с наземным аплинком delay падает на сотни мс.
В12 — а как вам вот такой трейс:
В14 — на спутниковых линках это заметно совсем хорошо, если вдруг попадается нод с наземным аплинком delay падает на сотни мс.
Как такое возможно? Я про адреса 169.254 в конце.
Скажу по секрету — я тоже иногда использую link local адресацию под point-to-point линки. Почему бы и нет? Роутиться эти префиксы не должны даже внутри компании.
Да легко. Это пакет с адресом назначения или источника 169.254 сам маршрутизироваться не может. А вот использовать эти адреса в качестве адресов маршрутизаторов, так же, как и приватные — можно. Выше мы тут обсуждали, фактически этот адрес шлюза (next hop) нужен, чтобы сделать arp-запрос (или что там за технология в вашем канальном уровне) и узнать канальный адрес next hop. После этого пакеты шлются туда, адреса-то у них при этом не меняются.
Ну то есть, на хопе 8 есть правило: 193.104.119.210 доступен через 169.254.254.38. Ну он узнаёт его MAC адрес и пересылает туда пакет, а в пакете адреса остались как были — от 212.199.17.111 до 193.104.119.210.
Когда пакет идёт обратно, у хопа 9 срабатывает правило, что 212.199.17.111 доступен через 169.254.255.6. Он узнаёт его MAC-адрес и шлёт туда пакет от 193.104.119.210 до 212.199.17.111.
Как видите, link-local адреса используются исключительно для ARP-запросов при получении физического адреса следующей системы, не более того. Они в этом отношении ничем не хуже любых других.
Ну то есть, на хопе 8 есть правило: 193.104.119.210 доступен через 169.254.254.38. Ну он узнаёт его MAC адрес и пересылает туда пакет, а в пакете адреса остались как были — от 212.199.17.111 до 193.104.119.210.
Когда пакет идёт обратно, у хопа 9 срабатывает правило, что 212.199.17.111 доступен через 169.254.255.6. Он узнаёт его MAC-адрес и шлёт туда пакет от 193.104.119.210 до 212.199.17.111.
Как видите, link-local адреса используются исключительно для ARP-запросов при получении физического адреса следующей системы, не более того. Они в этом отношении ничем не хуже любых других.
Как видите, link-local адреса используются исключительно для ARP-запросов при получении физического адреса следующей системы, не более того.
Не. В данном случае они однозначно используются в качестве L3 адресов для обмена протоколов маршрутизации. Но сути это не меняет
:) я не стал уточнять, откуда «на хопе 8 есть правило: 193.104.119.210 доступен через 169.254.254.38» и почему «у хопа 9 срабатывает правило, что 212.199.17.111 доступен через 169.254.255.6».
Из трейса мы точно знаем, что такие правила там ЕСТЬ (как минимум на восьмом хопе). А вот про динамическую маршрутизацию в трейсе ничего не написано. Может, там садомазо-админ всё настроил статически, откуда вы знаете?
Из трейса мы точно знаем, что такие правила там ЕСТЬ (как минимум на восьмом хопе). А вот про динамическую маршрутизацию в трейсе ничего не написано. Может, там садомазо-админ всё настроил статически, откуда вы знаете?
Кстати, по поводу В12 и IPv6. В IPv6 link-local на интерфейсе есть всегда (ну или почти всегда), и иногда это очень удобно, т.к. через него можно маршрутизировать. Например, выдал вам провайдер /64 IPv6, причем только одну, а вы ну очень не хотите использовать бридж, то можно спокойно маршрутизировать прямо через link-local адреса. У меня сейчас вот так:
valdikss@valaptop:~ % ip -6 a s wlan0
2: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
inet6 2002:5c2a:1f7f:2000:ddf9:895c:f491:9369/64 scope global temporary dynamic
valid_lft 27sec preferred_lft 17sec
inet6 2002:5c2a:1f7f:2000:223:15ff:fe5b:240c/64 scope global dynamic
valid_lft 27sec preferred_lft 17sec
inet6 fe80::223:15ff:fe5b:240c/64 scope link
valid_lft forever preferred_lft forever
valdikss@valaptop:~ % ip -6 r
fe80::/64 dev eth0 proto kernel metric 256
fe80::/64 dev wlan0 proto kernel metric 256
default via fe80::2e0:4cff:fe86:7001 dev wlan0 proto static metric 1
default via fe80::2e0:4cff:fe86:7001 dev wlan0 proto ra metric 1024 expires 29sec
valdikss@valaptop:~ % traceroute -6 ipv6.google.com
traceroute to ipv6.google.com (2a00:1450:4010:c04::68), 30 hops max, 80 byte packets
1 2002:5c2a:1f7f:2000::1 (2002:5c2a:1f7f:2000::1) 8.667 ms 8.605 ms 8.580 ms
2 * * *
3 KHOUSE-TR2.TCINET.RU (2001:6d0:ffd1:301::1) 21.487 ms 21.448 ms 21.413 ms
4 msk-ix-gw2.google.com (2001:7f8:20:102::246:232) 21.306 ms 21.299 ms 21.265 ms
5 2001:4860::1:0:2aae (2001:4860::1:0:2aae) 58.533 ms 2001:4860::1:0:2ab1 (2001:4860::1:0:2ab1) 58.440 ms 58.406 ms
6 2001:4860::8:0:26e5 (2001:4860::8:0:26e5) 58.391 ms 75.739 ms 2001:4860::8:0:26e6 (2001:4860::8:0:26e6) 54.824 ms
7 2001:4860::2:0:2ab0 (2001:4860::2:0:2ab0) 54.693 ms 2001:4860::2:0:2aaf (2001:4860::2:0:2aaf) 54.726 ms 56.224 ms
8 lb-in-x68.1e100.net (2a00:1450:4010:c04::68) 55.811 ms 54.698 ms 55.805 ms
valdikss@valaptop:~ % ip -6 r g 2a00:1450:4010:c04::68
2a00:1450:4010:c04::68 from :: via fe80::2e0:4cff:fe86:7001 dev wlan0 src 2002:5c2a:1f7f:2000:ddf9:895c:f491:9369 metric 0
cacheБольше того, если у вас в сети работает radvd, на компах и будет в маршруте по умолчанию указан link-local адрес шлюза. Т.е. каждый может легко столнкнуться с машрутизацией белых адресов через link-local-адреса.
Не совсем понял пример с тем, как можно избежать бриджа.
Допустим у нас /64 на внешнем интерфейсе машины А, и link-local на внутреннем, к которому подцеплена машина Б. В принципе, машина Б может использовать link-local адрес машины А с внутреннего интерфейса, но назад то как? Внешний маршрутизатор по ND будет искать машину Б, машина А об этом не в курсе, ND-пакеты не маршрутизируются, никто никого не видит.
Собственно, почему и возникает необходимось в линухах делать proxy_ndp.
Допустим у нас /64 на внешнем интерфейсе машины А, и link-local на внутреннем, к которому подцеплена машина Б. В принципе, машина Б может использовать link-local адрес машины А с внутреннего интерфейса, но назад то как? Внешний маршрутизатор по ND будет искать машину Б, машина А об этом не в курсе, ND-пакеты не маршрутизируются, никто никого не видит.
Собственно, почему и возникает необходимось в линухах делать proxy_ndp.
Хм, у меня proxy_ndp не включен ни на одном интерфейсе.
Получается так, что для связи между маршрутизатором и клиентом используются link-local адреса, и, в то же время, и у клиента, и у роутера настроены обычные ipv6 global адреса. Клиент отправляет пакет с source-адресом из global через роутер, который доступен по link-local, ну и ответ ему так же приходит.
Получается так, что для связи между маршрутизатором и клиентом используются link-local адреса, и, в то же время, и у клиента, и у роутера настроены обычные ipv6 global адреса. Клиент отправляет пакет с source-адресом из global через роутер, который доступен по link-local, ну и ответ ему так же приходит.
Интересно. Давайте копнем детальнее. Конкретный пример – это hetzner, который отдает на машины один /64. Проблема – сделать IPv6 внутри KVM-виртуалок на этой машине.
Допустим на хосте у нас есть конкретный IPv6 адрес: 2a01:fad:120:6f3a::2/64, и мы хотим заиметь виртуалку с адресом 2a01:fad:120:6f3a::10. У меня возникает следующая проблема:
Шлем «из мира» пакет на 2a01:fad:120:6f3a::10.
Пакет падает на маршрутизатор хецнера, который начинает у всех спрашивать, а не видел ли кто тут 2a01:fad:120:6f3a::10? (эти пакеты видно на внешнем интерфейсе хоста).
Поскольку хост непосредственно про этот адрес ничего не знает, то он ND успешно игнорирует, роутер шлет пакет назад – не, нету тут такого.
proxy_ndp «лечит» эту ситуацию тем, что хост среди ND запросов начинает обращать внимание на запросы с IP 2a01:fad:120:6f3a::10 (отвечая – шли сюда). Когда конкретный пакет падает на интерфейс правила маршрутизации позволяют перекинуть его с eth0 на vnet0 к гостю и все работает.
Минусы – надо поштучно добавлять все нужные IPv6 адреса в proxy_ndp.
ЧЯДНТ?
Допустим на хосте у нас есть конкретный IPv6 адрес: 2a01:fad:120:6f3a::2/64, и мы хотим заиметь виртуалку с адресом 2a01:fad:120:6f3a::10. У меня возникает следующая проблема:
Шлем «из мира» пакет на 2a01:fad:120:6f3a::10.
Пакет падает на маршрутизатор хецнера, который начинает у всех спрашивать, а не видел ли кто тут 2a01:fad:120:6f3a::10? (эти пакеты видно на внешнем интерфейсе хоста).
Поскольку хост непосредственно про этот адрес ничего не знает, то он ND успешно игнорирует, роутер шлет пакет назад – не, нету тут такого.
proxy_ndp «лечит» эту ситуацию тем, что хост среди ND запросов начинает обращать внимание на запросы с IP 2a01:fad:120:6f3a::10 (отвечая – шли сюда). Когда конкретный пакет падает на интерфейс правила маршрутизации позволяют перекинуть его с eth0 на vnet0 к гостю и все работает.
Минусы – надо поштучно добавлять все нужные IPv6 адреса в proxy_ndp.
ЧЯДНТ?
Вы, похоже, правы. Я себя не могу пинговать извне, как будто за NAT сижу, только в IPv6. Это, конечно, может быть из-за моего 6to4 шлюза (я замечал проблемы соединения с ним), но, похоже, это именно из-за того, что вы описали. Спасибо, что открыли мне глаза, я бы даже не понял, почему я недоступен из интернета.
Правильно всё вы делаете.
хорошие вопросы для собеседования, если надо показательно завалить кандидата. спасибо, добавил в избранное :)
забавно будет, если кандидат, так же решит, показательно блеснуть знаниями которые прочитал здесь
тогда, возможно, этого кандидата валить не нужно, он подходит?
ну можно задать другие вопросы, не менее каверзные, которых здесь не прозвучало. Например задать сеть в духе «мы взяли 10 линков на 100м, соединили их пятипортовыми 100 мегабитными свитчами, и получили таким образом 1км 100mbit ethernet». И попросить описать проблемы, с которыми могут встретиться пользователи такой сети :)
По поводу 15. Сколько угодно примеров, когда сканы идут с приватных адресов, dns-запросы, да мало ли что еще.
Такое ощущение, что их не фильтрует никто на выход. Прикольный побочный эффект у тех, кто этого не учитывает — ответы на такие запросы летят внутрь ЛВС. Когда это не просто ЛВС, а большая межрегиональная приватная сетка крупной конторы на базе L3 VPN (например), такие ответы часто находят свою цель. Иногда это выглядит для владельца приватного диапазона, совпавшего с таким левым src как скан или даже подобие дос-а.
Еще у одного провайдера, который используем как резерв, обнаружилась интересная особенность — он из своей сети выпускает без проблем пакеты с белыми-не-своими src. Забавная получалась ассиметрия. Можно юзать для затруднения анализа трафика со стороны провайдера :)
Такое ощущение, что их не фильтрует никто на выход. Прикольный побочный эффект у тех, кто этого не учитывает — ответы на такие запросы летят внутрь ЛВС. Когда это не просто ЛВС, а большая межрегиональная приватная сетка крупной конторы на базе L3 VPN (например), такие ответы часто находят свою цель. Иногда это выглядит для владельца приватного диапазона, совпавшего с таким левым src как скан или даже подобие дос-а.
Еще у одного провайдера, который используем как резерв, обнаружилась интересная особенность — он из своей сети выпускает без проблем пакеты с белыми-не-своими src. Забавная получалась ассиметрия. Можно юзать для затруднения анализа трафика со стороны провайдера :)
И да, если брать ответ автора на 15 — то не столько важно понять, откуда эти адреса берутся на интерконнетах маршрутизаторов, сколько то, что немаршрутизируемость — это значит на такой адрес нельзя доставить пакет, а вот адерс источинка может быть любым, в том числе и немаршрутизируемым в инетах. Еще бывает обратная ситуевина. Клиент, делая трейс до локального ресурса провайдера недоумевает — почему с серыми адресами в перемешку белые?
В17. При пинге с маршрутизатора cisco теряется первый пакет. Почему это происходит?
Во-первых, первый пакет теряется только если нет такой записи в arp таблице. Я слышал такое объяснение от инженеров cisco — IOS обращается к arp таблице, не находит там нужной записи. После этого отправляет arp-запрос и дропает ICMP пакет чтобы не хранить в памяти пакет для неизвестного канального адреса. А на следующий пинг запись в arp таблице уже есть. Дроп оправдывают одним из ранних rfc.
Во-первых, первый пакет теряется только если нет такой записи в arp таблице. Я слышал такое объяснение от инженеров cisco — IOS обращается к arp таблице, не находит там нужной записи. После этого отправляет arp-запрос и дропает ICMP пакет чтобы не хранить в памяти пакет для неизвестного канального адреса. А на следующий пинг запись в arp таблице уже есть. Дроп оправдывают одним из ранних rfc.
Дополнение к вопросу В1 — почему используется зеленая пара, а не симметричная синей коричневая?
Вопрос скорее Винту Серфу — почему в IPv4 не стали использовать динамическую длину адреса, используя Internet Header Length > 5 и поле Options для расширения длины адреса (как расширяется телефонный номер при добавлении кода города, страны)? Это бы решило проблему количества IPv4 адресов не нарушая стандарта и без потери совместимости со старым оборудованием и софтом.
Вопрос скорее Винту Серфу — почему в IPv4 не стали использовать динамическую длину адреса, используя Internet Header Length > 5 и поле Options для расширения длины адреса (как расширяется телефонный номер при добавлении кода города, страны)? Это бы решило проблему количества IPv4 адресов не нарушая стандарта и без потери совместимости со старым оборудованием и софтом.
У ipv4 много фич для хорошей работы в арпанете. Сам по себе протокол хороший, но создавался он не для высокоскоростных сетей с низким уровнем ошибок, поэтому проще было разработать новый протокол а не допиливать старый. А по трудоемкости переходы на ipv6, ipv5 и расширение адресации ipv4 одинаковые.
Пардон, запутался, синяя пара нипричем.
Спрошу иначе — почему разводка такая «кривобокая», а не симметричная? Можно ведь использовать по два крайних контакта в 8p8с. 1 и 2 для одной пары, 7 и 8 для другой.
Спрошу иначе — почему разводка такая «кривобокая», а не симметричная? Можно ведь использовать по два крайних контакта в 8p8с. 1 и 2 для одной пары, 7 и 8 для другой.
В11. Чем принципиально отличается обратная маска от обычной?
Тем, что первая оперирует хостами, а вторая — сетями. Всегда. Они используются для разных задач.
В14. На одном из хопов по всем трём результатам трассировки величина задержки выше, чем на следующем
Коротко:
На хардварных платформах отправка отклика time exceeded реализована на совершенно других чипах, нежели передача транзитных пакетов.
Длинно:
Возьмем к примеру мой любимый Cat6500. Его «мозги» (то, что отзывается на пинги, обменивается маршрутами, принимает ssh соединения и т.д.) сосредоточены на супервизоре в MSFC. MSFC отвечает за программирование PFC (ну и DFC при их наличии), в котором и осуществляется обработка и передача пакетов. По хорошему, ни один транзитный пакет не должен попадать в MSFC.
Пакет с TTL 0 не может быть обработан PFC, так как тут требуется более интеллектуальная обработка, чем та, на которую он способен (требуется сгенерить time exceeded и отправить его назад отправителю (или вперед получателю в случае MPLS, да не суть)). Потому такой пакет переадресуется MSFC. А тот может в данный момент быть нагружен, ICMP на нем не в приоритете, потому он может на несколько миллисекунд отложить отправку ответа, пока не закончит с более важными делами.
Но да, причиной может быть и возврат time exceedeed другим маршрутом.
В16. Чем обусловлены такие задержки при трассировке?
При трассировке по MPLS пакеты отскакивают от PE, а не от CE — PE уже знает, как вернуть пакет обратно. Разумеется, пакет с истекшим TTL не может быть передан CE.
В17. При пинге с маршрутизатора cisco теряется первый пакет. Почему это происходит?
Кстати — обычно сгенерированный локально пакет как раз будет не отброшен, а задержан. И для первого пакета будет высокий RTT.
Автор, оформите ответы тегом «спойлер» после каждого вопроса, это удобно.
Для чего нужен адрес сети? Почему его нельзя назначить хосту?
Для того чтобы быстро определить принадлежность IP данной сети:
ipaddr & netmask == netaddr Чем проще метод определения принадлежности — тем проще (и быстрее) маршрутизация
В общем-то это не даёт ответ на вопрос, почему нельзя использовать адрес .0 для хоста. То есть понятно, что нам это непривычно, но теоретических препятствий этому не вижу. Впрочем возможный ответ уже дали, я его добавил в топик.
Отсылка в книгу не совсем верная. Цитата из книги:
И все это относится к этапу classful addressing scheme — когда нельзя было задать маску /23 или /9, а были только фиксированные /8, /16 и /24. На том этапе не нужна была и маска сети как таковая, так как класс сети (и маску соотв.) можно было определить по первым битам адреса (
Но когда появилась идея CIDR, т.е. возможность «резать» адресное пространство в практически произвольных пропорциях — появилась необходимость в маске и правильном броадкасте. Поэтому уже сделать маску сети с единицами, а броадкаст нулями не выйдет из-за того что броадкаст будет одинаковым для нескольких сетей.
В принципе, этой же цитатой можно объяснить и почему хосту нельзя назначить адрес сети — так как существовали бажные реализации, которые могли интерпретировать такой адрес как броадкаст и пакет был бы отправлен не одному адресату, а всей сети.
Unfortunately, an early release of TCP/IP code that accompanied Berkeley UNIX incorrectly used all zeroes for broadcast. Because the error stil survives, TCP/IP software often includes an option that allows a site to use all zeroes for directed broadcast.
И все это относится к этапу classful addressing scheme — когда нельзя было задать маску /23 или /9, а были только фиксированные /8, /16 и /24. На том этапе не нужна была и маска сети как таковая, так как класс сети (и маску соотв.) можно было определить по первым битам адреса (
0... - /8, 10... - /16, 110... - /24). В том случае броадкастом и адресом сети могло быть что угодно, но согласованное между всеми заинтересованными лицами. Но когда появилась идея CIDR, т.е. возможность «резать» адресное пространство в практически произвольных пропорциях — появилась необходимость в маске и правильном броадкасте. Поэтому уже сделать маску сети с единицами, а броадкаст нулями не выйдет из-за того что броадкаст будет одинаковым для нескольких сетей.
В принципе, этой же цитатой можно объяснить и почему хосту нельзя назначить адрес сети — так как существовали бажные реализации, которые могли интерпретировать такой адрес как броадкаст и пакет был бы отправлен не одному адресату, а всей сети.
Или для чего нужен широковещательный адрес?
Все из-за той же простоты и скорости. Если пришел пакет с
dstip, то проверить предназначен ли он нам достаточно следующего условия: dstip & myip == myipЭто условие будет правдой и в случае если
dstip == myip и если dstip будет броадкаст адресом.Можно было бы использовать для него адрес сети.
Пока сети были classfull — да, вполне можно было попробовать. Но вы попробуйте отличить сеть 192.168.1.0/24 и 192.168.1.0/25 — адрес сети у них будет одинаковый, а в IP заголовке передается только один адрес (без маски). Поэтому используется броадкаст — так как он различается в случае classless сетей :)
В5. Знаете ли вы, что реальная битовая скорость Fast Ethernet 125 Мб/с? Почему так?
На этот вопрос лет 10-12 назад на одном семинаре бородатый дед из НИИ Дальсвязи отвечал так: «потому, что „без темной сущности физики“ для технологии 100Base-T рабочая частота 125 МГц, а для 10Base-T около 10 МГц.»
Следовал вопрос :«а как же 1000Base-T, ведь у кабеля типа „витая пара“ пропускная способность не выше 350МГц?»
«Как-как, а гармоники на что?!»
:)
На этот вопрос лет 10-12 назад на одном семинаре бородатый дед из НИИ Дальсвязи отвечал так: «потому, что „без темной сущности физики“ для технологии 100Base-T рабочая частота 125 МГц, а для 10Base-T около 10 МГц.»
Следовал вопрос :«а как же 1000Base-T, ведь у кабеля типа „витая пара“ пропускная способность не выше 350МГц?»
«Как-как, а гармоники на что?!»
:)
Вопрос 7 — ваш ответ неправильный.
LACP прекрасно определяет unidirectional links. Тайм-аут либо 1, либо 30 секунд — есть два механизма в lacp, fast и slow transmission.
UDLD/BFD нужны только для уменьшения времени реакции. Более того, в свое время пришлось выпустить отдельный RFC по BFD поверх LACP, т.к. BFD изначально протокол L3 и воспринимает весь PortChannel как один агрегированный линк и может определить только падение всего линка.
LACP прекрасно определяет unidirectional links. Тайм-аут либо 1, либо 30 секунд — есть два механизма в lacp, fast и slow transmission.
UDLD/BFD нужны только для уменьшения времени реакции. Более того, в свое время пришлось выпустить отдельный RFC по BFD поверх LACP, т.к. BFD изначально протокол L3 и воспринимает весь PortChannel как один агрегированный линк и может определить только падение всего линка.
B. 14 Кроме вашего ответа, есть еще другая ситуация: когда ЦПУ маршрутизированного устройства загружено, а маршрутный процессор нет, то пакет маршрутизируется без задержек, когда как ответ от ЦПУ маршрутизатора на всякие icmp запросы может вызвать задержку.
Б. 17 — это дела вендора, у каждого вендора есть свои закидоны на эту тему и от железки к железке внутри вендора тоже.
Б. 17 — это дела вендора, у каждого вендора есть свои закидоны на эту тему и от железки к железке внутри вендора тоже.
По поводу идентификатора сети. Хосту вообще запрещается назначать адрес идентификатора его же сети, по правилам распределения адресов нельзя указывать идентификатор хоста, состоящий только из нулей или только из единиц. Почему? Думаю уже мало кто вспомнит, возможно из-за аппаратного обеспечения, чтобы хосты нумеровались с единицы и так далее, а не с нуля. А почему не с нуля — это надо глубоко лезть в аппаратное обеспечение, наверняка там найдется ответ у какого-нибудь вендора.
В1 — предполагаю что так удобно для подсоединения к встроенным в разъем трансформаторам, потому что с точки зрения удобства трассировки плат — только гемор лишний, с точки зрения кабеля — фиолетово вообще тоже — остается только какое то удобство в подключении внутри разъема трансформаторов
Мерзкая картинка для привлечения внимания:(
Ещё один вопрос, который любят на задавать на интервью — почему когда в трейсе, в котором последний девайс — циска, второй реплай вылетает, и как это починить.
Никогда если честно такого не видел :). И какой же ответ?
Там стоит ограничение на частоту отправки реплаев, чтобы этим не перегрузить процессор.
Решается командой ip icmp rate-limit unreachable [ms]. По умолчанию стоит не более 1 unreachable в 500мс.
Решается командой ip icmp rate-limit unreachable [ms]. По умолчанию стоит не более 1 unreachable в 500мс.
А почему тогда это может не работать? Ограничение стоит, но реплаи не теряются.
В10: Может ли адрес 10.0.1.0 быть использован для адреса хоста?
Вроде ещё может быть в случае соединения точка-точка и длине маски сети 31. Хотя не факт, что это есть в стандарте и, говорят, не все железки могут поддерживать.
P.S. Беглым просмотром результатов поиска в яндексе нашёл ссылку на RFC 3021, которое вроде как разрешает 255.255.255.254. Сам ещё не читал, не успею отредактировать запись иначе.
Зачем так сложно? Запихните его в сеть /8 и хосты смогут иметь любые адреса от 10.0.0.1 до 10.255.255.254.
Все верно можно использовать маску /31 для соединений точка точка согласно RFC 3021. Версия операционки маршрутизатора (если это Cisco) должна быть не ниже 12.2T.
У вас ошибка, вместо 240.0.0.0/4 нужно 224.0.0.0/4.
Адрес сети в виде адреса хоста можно использовать, как уже написали выше, согласно RFC 3021.
Адрес сети в виде адреса хоста можно использовать, как уже написали выше, согласно RFC 3021.
По поводу пауз между посылками сразу вспомнился Serial Experiments Lain. Эти паузы оставшиеся в «наследство» использовались для скрытой активности. Сказка, сказкой да в ней намек…
Уточните, пожалуйста, В10.
Разве может быть крайний байт для адреса хоста быть нулем (в примере 10.0.1.0)? Мне всегда казалось, что это только для масок сетей.
Разве может быть крайний байт для адреса хоста быть нулем (в примере 10.0.1.0)? Мне всегда казалось, что это только для масок сетей.
В ряде случаев может
Да, может, в двух случаях:
1) Использование специальной конфигурации маршрутизатора, позволяющей назначать адрес сети и широковещательный хостам. Например нередко используют маску /31 для р2р линков
2) Например для сети 10.0.0.0.23 диапазон адресов будет 10.0.0.1-10.0.1.254 и абсолютно все адреса можно использовать.
1) Использование специальной конфигурации маршрутизатора, позволяющей назначать адрес сети и широковещательный хостам. Например нередко используют маску /31 для р2р линков
2) Например для сети 10.0.0.0.23 диапазон адресов будет 10.0.0.1-10.0.1.254 и абсолютно все адреса можно использовать.
> Ethernet совмещает в себе функции канального и физического уровня модели OSI
Не упоминайте ISO всуе.
Идеи заложенные в OSI противоречат реализованным в Ethernet. Не может одно описываться другим, совмещать и прочий бред. ISO это не семь прямоугольничков, а толстый подробный документ. Все эти соответствия появились в результате фантазий об универсальном стеке (реализации) в ОС и железках.
Не упоминайте ISO всуе.
Идеи заложенные в OSI противоречат реализованным в Ethernet. Не может одно описываться другим, совмещать и прочий бред. ISO это не семь прямоугольничков, а толстый подробный документ. Все эти соответствия появились в результате фантазий об универсальном стеке (реализации) в ОС и железках.
Да ладно вам… Стек TCP/IP в целом неплохо накладывается на модель OSI (те самые прямоугольники). И мне референсная модель OSI нравится больше, чем модель TCP/IP:
1) Не надо было сплющивать канальный и физический уровни в один.
2) L5 в самом TCP/IP все-таки иногда существует (хотя не так явно, как у ISO). К примеру, может определяться куками в случае HTTP. И даже для сетевика L5 существует, это довольно важный вопрос при работе с балансировщиками. L6 у TCP/IP тоже есть хотя бы в виде SSL. А в модели TCP/IP ни одного из них нет.
1) Не надо было сплющивать канальный и физический уровни в один.
2) L5 в самом TCP/IP все-таки иногда существует (хотя не так явно, как у ISO). К примеру, может определяться куками в случае HTTP. И даже для сетевика L5 существует, это довольно важный вопрос при работе с балансировщиками. L6 у TCP/IP тоже есть хотя бы в виде SSL. А в модели TCP/IP ни одного из них нет.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Каверзные сетевые вопросы