Я пытаюсь играть (в GNS3, если это имеет значение) с очень простой топологией из трех маршрутизаторов, подключенных через концентратор. Когда я пытаюсь выполнить эхо-запрос от одного маршрутизатора к другому, скажем, от R1 до R2. R3 отвечает сообщением перенаправления ICMP, заставляя R1 повторно отправить запрос ping на R2. Цикл продолжает бесконечно сеять хаос в моделируемой сети. Вопрос в том, почему R3 отвечает R1 на сообщение ICMP, не адресованное ему (эхо-запрос от R1 к R2).
Таблица маршрутизации R3: -
R3>enable
Password:
R3#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
O 10.1.0.0/16 [110/2] via 192.168.0.1, 00:58:17, FastEthernet1/0
O 10.2.0.0/16 [110/2] via 192.168.0.2, 00:58:17, FastEthernet1/0
C 10.3.0.0/16 is directly connected, FastEthernet0/0
L 10.3.0.1/32 is directly connected, FastEthernet0/0
C 192.168.0.0/16 is directly connected, FastEthernet1/0
192.168.0.0/32 is subnetted, 1 subnets
L 192.168.0.3 is directly connected, FastEthernet1/0
R3#
ОБНОВЛЕНИЕ: проблема заключается не в перенаправлении ICMP, а в том факте, что любой маршрутизатор поместит пакет проверки связи ICMP, который он не может обработать, обратно в интерфейс, который он прибыл из лавинной сети до истечения срока действия TTL.
Оригинальный ответ
Это происходит из-за вашей топологии. Я предполагаю, что вы пингуете подсеть 192.168.0.0/16? Даже если вы отправляете эхо-запрос на внешние интерфейсы (10.1.0.0/16, 10.2.0.0/16, 10.3.0.0/16) на маршрутизаторах, они все равно маршрутизируются через подсеть 192.168.0.0 на пути к месту назначения. Причина, по которой это происходит, заключается в том, что вы используете концентратор для подключения всех трех компьютеров в одной подсети (а не коммутатор). По умолчанию концентратор предназначен для широковещательной рассылки всех сообщений, полученных на всех его интерфейсах (в отличие от коммутатора, который через ответы узнает, какие машины подключены к его интерфейсам).
Итак, пакет ICMP отправляется с R1, и когда он попадает в концентратор, он транслируется на R2 и R3 (а также на R1). Это эффективно дублирует пакет в триплете. Дублирующиеся пакеты попадают в R1, R2 и R3 и запускают правило пересылки:
C 192.168.0.0/16 is directly connected, FastEthernet1/0
Эффективно возвращает пакеты обратно в концентратор. Промойте и повторите, и вы получите наводненную сеть умножения пакетов ICMP. Решение: заменить концентратор на коммутатор или внедрить no ip redirects
правило, предложенное Роном.
Приложение: сравнение и противопоставление концентратора и коммутатора, подробная механика коммутации пакетов с различными аппаратными протоколами
Концентратор:
Концентратор - это простое устройство, которое знает только одно: транслировать то, что получает, на всех интерфейсах. Когда пакет приходит от одного из трех маршрутизаторов в центре вашей сети, концентратор делает то, что умеет:
Протокол ICMP
Протокол ICMP имеет некоторые особенности по сравнению с другими сетевыми протоколами. Он находится на уровне Интернета (или IP), который является уровнем 3 в модели TCP / IP. Многие люди на первый взгляд предполагают, что он будет существовать на уровне 2 с другими протоколами приложений, но это не так. Это потому, что ICMP изначально был разработан как протокол сообщений об ошибках. Протокол ICMP сообщает метаданные об уровне IP в случае исключительного поведения, такого как потеря пакетов или недоступность адресатов. Таким образом, когда пакет ICMP поступает в устройство (например, маршрутизатор), устройство проверяет, куда он направил пакет ICMP, и, если его местом назначения является само устройство, оно отвечает новым сообщением (например, PING REPLY). Если его местом назначения является другое устройство, оно уменьшает время жизни (TTL) и отправляет пакет на своем пути в соответствии с таблицей маршрутизации устройства.
Таблица маршрутизации Cisco
Следует рассмотреть третий фрагмент головоломки - это таблица маршрутизации устройства Cisco. Мы знаем, как выглядит таблица маршрутизации после того, как сеть некоторое время работает. В ответ на ваш вопрос:
Почему какой-либо маршрутизатор, направленный через 192.168.0.0 через сеть назначения (скажем, 10.1.0.0), напрямую подключен к нему и не передается через какой-либо маршрутизатор.
Это связано с механизмами обнаружения сети на маршрутизаторах Cisco. Обратите внимание на эти строки в таблице маршрутизации:
O 10.1.0.0/16 [110/2] via 192.168.0.1, 00:58:17, FastEthernet1/0
O 10.2.0.0/16 [110/2] via 192.168.0.2, 00:58:17, FastEthernet1/0
Буква O в начале означает OSPF, собственный алгоритм маршрутизации, который заполняет таблицу маршрутизации на устройстве Cisco. Я не уверен в деталях того, как заполняется таблица маршрутизации, но это не имеет значения. Каждый маршрутизатор знает, что он может получить доступ к внешние интерфейсы двух других маршрутизаторов отправляя трафик через подсеть 192.168.0.0/16. Таким образом, когда пакет, предназначенный для любого из этих интерфейсов (например, ICMP PING REQUEST), поступает в маршрутизатор от концентратора, каждый маршрутизатор знает, что он может достичь сети назначения через локальную подсеть. Следовательно, пока пакет не привязан к самому устройству, у этих пакетов будет уменьшено их TTL, и они будут перенаправлены обратно в концентратор (следующая диаграмма происходит на каждом устройстве, которое получает пакет, не привязанный к себе и не отправленный. от себя):
Как видите, эти три вещи вместе создают цикл, который продолжает пересылать и генерировать дублирующиеся пакеты ICMP, пока с пакетами не произойдет одно из следующих событий:
В моем ответе может быть несколько обобщений, но вы уловили картину. Концентратор генерирует больше пакетов, чем потребляет.
Как коммутатор ведет себя по-разному (и почему мы используем коммутаторы вместо концентраторов)
Когда вы впервые подключаете коммутатор, он такой же тупой, как и концентратор. Однако основное отличие состоит в том, что переключатель может учиться откуда приходят и отправляются пакеты, обращая внимание на трафик, проходящий через устройство. Когда коммутатор впервые встречает пакет, он не знает, к какому интерфейсу подключен пункт назначения, поэтому пересылает его всем подключенным интерфейсам. Когда он это делает, он записывает исходный и целевой IP-адреса в свою таблицу коммутаторов. Когда ответ, исходящий от этого пункта назначения (и адресованный исходному источнику), обнаружен, он завершает запись в таблице переключения. После этого переключатель знает, какие IP-адреса подключены к соответствующим интерфейсам. С этого момента, когда он принимает пакет, он пересылает его только на тот интерфейс, где он знает, что пункт назначения подключен. Это устраняет проблему дублирования пакетов.
MAC против IP-адреса и маршрутизации пакетов с Ethernet против PPP
Ты спрашивал:
Почему маршрутизатор R3, получающий пакет с MAC-адресом R2 (отправленный с R1), вообще будет отвечать на уровне ICMP?
Маршрутизация пакетов с использованием Ethernet и других протоколов, использующих MAC-адреса
Пакеты могут начинаться с пустых или широковещательных MAC-адресов назначения (в зависимости от стандарта оборудования). С Ethernet аппаратный стандарт (и несколько других, таких как Wi-Fi), когда любой пакет отправляется с маршрутизатора или хост-машины, IP-адрес назначения проверяется по таблице протокола разрешения адресов (ARP) (это таблица, которая отслеживает MAC адреса). Если обнаружено совпадение с локально подключенным компьютером в той же подсети, то поле MAC-адреса пакета обновляется перед его отправкой в сеть. ОДНАКО, если пакет предназначен для IP-адреса в другой подсети, MAC-адрес устанавливается на MAC-адрес шлюза по умолчанию или шлюза, к которому он знает, что может достичь IP-адреса назначения (поскольку машина знает, что место назначения на другая сеть).
Маршрутизация пакетов PPP, SLIP и другие аппаратные протоколы, не использующие MAC-адреса
Как правило, если два маршрутизатора (шлюза) подключены напрямую, без промежуточных маршрутизаторов, это считается "одноранговым" соединением. Как правило, эти типы подключений не являются Ethernet и используют другие стандарты. Наиболее распространенным из этих стандартов является протокол точка-точка (PPP), но есть и другие, такие как SLIP и PPPoE (PPP через Ethernet). Если маршрутизатор рассматривает записи SPF «C» или «O» в своей таблице маршрутизации как одноранговые соединения, то MAC-адрес в пакете может быть установлен на пустые значения или быть установлен на BROADCAST, или они могут использовать фиктивные значения или вообще не использовать MAC-адреса (однако это может отличаться в зависимости от стандартов аппаратного протокола, с которым они связаны, с которым я не знаком в данном случае). Чтобы точно сказать, что происходит, вам нужно будет больше узнать об аппаратных стандартах маршрутизатора Cisco и о том, как они работают с MAC-адресами и одноранговыми соединениями и какой аппаратный протокол они используют (который, скорее всего, будет PPP по умолчанию. ).
Последствия в этом сценарии
Поскольку пакеты передаются по сети, каждый принимающий маршрутизатор выполняет одно из двух (в зависимости от используемого аппаратного протокола):
Это происходит на каждом шаге в сети, пока маршрутизатор не обнаружит, что IP-адрес назначения находится в его локальной подсети Ethernet (или другом стандарте, использующем MAC). Именно так переводятся адреса в аппаратный или физический уровень. Итак, чтобы ответить на ваш вопрос, в этом сценарии кажется, что все, что знает R3, - это то, что пакет предназначен для другой сети, к которой он может добраться через свой интерфейс f1 / 0. Его не волнует, какой MAC-адрес, потому что он использует протокол, который не использует MAC-адреса. По данным Microsoft:
Если посмотреть на поток, то MAC-заголовок, который виден на Ethereal, - это фиктивный заголовок Ethernet, добавленный между WANARP и NDISWAN. Таким образом, сеть отслеживает (например, ethereal) видит интерфейс PPP как Ethernet интерфейс. Но на проводе ... пакет не будет содержать заголовок Ethernet, вместо этого это будут заголовки TCP-> IP-> PPP
Поэтому вам не следует смотреть на MAC-адреса в сетевом мониторе как на реальные MAC-адреса.
Обратите внимание, что в вашей таблице маршрутизации нет шлюза по умолчанию:
Gateway of last resort is not set
Это, наряду с тем фактом, что основные записи перечислены как directly connected
, предполагает, что он будет рассматривать все свои соединения как одноранговые (и, следовательно, не зависит от MAC-адресов).
Кроме того, вы можете задаться вопросом, почему MAC-адреса не используются для PPP или, в более общем плане, для сетевой адресации в целом. Посмотрите этот пост Вот. Первый комментарий к принятому ответу подтверждает то, что я сказал:
Я бы добавил, что MAC-адреса в конечном итоге используются в IP-коммуникациях, когда компьютеры определяют, что они находятся в одной подсети ... Layer-3 / IP-адресация в основном используются маршрутизаторами. и используется хостом только для определения того, находится ли пункт назначения в той же подсети. (Кредит Шону С.)