Сия публикация родилась из заметки «для себя». Заметка же родилась в процессе подготовки к ICND1 и чтения замечательного учебника от г-на Odom'a. На этапе прочтения главы о статической маршрутизации, стало интересно, как будет маршрутизироваться трафик, если:
Найдя полученный опыт полезным для усвоения основ различий в работе протоколов 2 уровня, я решил им поделиться с другими начинающимителекоммутаторами инженерами.
Схема для тестирования была не долго думая собрана в Packet-Tracer'e от дорогой, любимой Cisco, настроена и обкатана с прескорбным результатом — пинги не ходят, как маршруты ни пиши. Казалось бы, всё понятно — адреса то разные, вот маршрутизатор и не узнаёт того, к кому я его сватаю. С другой стороны, таблица маршрутизации заполнена предельно чётко — бери и отправляй, в чём проблема?
Явный и ясный ответ помог найти режим Simulation, доступный в Packet Tracer'e, который по пакетам и уровням показывает, что же у вас на сети происходят, как куда ходят фреймы и пакеты. И выяснил я для себя (а точнее, уяснил на практике уже изученное ранее по тому же Odom'у) следующее: что не работает на Ethernet, работает на HDLC.
Теперь перейдём кпальцам из заголовка конкретике.
Так выглядит схема с таблицами маршуртизации
У маршрутизаторов идентичные настройки (буковки слева выведены для маршрутизатора HDLC-R1, на маршрутизаторе EthernetR1 в конфигурации вместо интерфейса Serial 0/1/0 будет gigabitEthernet 0/0; аналогично и симметрично для правых маршрутизаторов).
Настройки, применявшиеся на маршрутизаторах:
HDLC-R1:
HDLC-R2:
При попытке отправить пинг по Ethernet, маршрутизатор находит соответствие в таблице маршрутизации (при этом сначала маршрутизатор ищет соответствие в CEF-таблице, см. англоязычные рисунки ниже). Далее маршрутизатор запаковывает ICMP Echo Request в IP, указывая source и destination ip, и переходит к взаимодействию на втором уровне, собирая frame. Маршрутизатор в ARP Таблице не находит соответствие IP адреса и MAC адреса получателя (т.к. Ethernet — не point-to-point подключение, т.е. на другом конце может быть много железа, и маршрутизатор таки должен понимать — кому же всё-таки отправлятьбандероль ip-пакет).
В связи с этим, маршрутизатор отправляет широковещательный ARP запрос, запаковав его в Ethernet frame c broadcast адресом FFFF:FFFF:FFFF.
Сосед получает L2 frame (Ethernet). Смотрит MAC адрес destination — видит, что это broadcast. Декапсулирует ethernet frame — находит там ARP запрос. При этом запрос прислали с source IP, который находится в другой подсети, нежели порт маршрутизатора, на который frame с ARP пришёл. Маршрутизатор отбрасывает этот пакет = пинга нет.
На Serail линке с протоколом HDLC, работающим на втором уровне, такого не происходит! Получатель принимает приходящий на порт пакет, молча распаковывает его (снимает заголовок HDLC), видит там свои IP адреса и отлично всё маршрутизирует в любую известную ему точку = отвечает на наш ping. Почему так происходит? HDLC, будучи P2P (point-to-point, точка-точка) протоколом, не оперирует MAC-адресами! Если мы выведем ARP таблицу для маршрутизаторов, подключенных серийными кабелями, они будут пусты несмотря на то, что связность между узлами есть (слева вывод для маршрутизаторов, подключенных по serial, справа — по ethernet) Заметьте, там, где ethernet, МАС-адреса соседа нету! Наш маршрутизатор EthernetR1 с ним так и не познакомился.
Для сравнения, frame HDLC:
И frame Ethernet с запросом ARP из рассматриваемого примера:
Таким образом, просто указав физический порт маршрутизатора, с которого доступен получатель, при использовании на L2 технологии Ethernet, нельзя получить удовлетворительного результата — маршрутизатор не выкинет с указанного интерфейса frame, т.к. не знает, на какой MAC его отправить, а broadcast'ом по L2 пакет unicast уровня L3 тоже отправлять никак нельзя.
Подводя итог — учите матчасть, ни в коем случае не ограничивайтесь теорией, даже если она кажется очень простой при прочтении. Пробуйте всё руками, задавайте сами себе вопросы и ищите на них ответы как при помощи своей головы/рук, так и пользуясь помощью более опытных товарищей, интернета, книг.
Всем спасибо!
- Адреса соединённых прямым линком интерфейсов двух маршрутизаторов находятся в разных подсетях (один конец имеет ip 192.168.1.1/24, другой — 172.16.0.1/16);
- В статическом маршруте обоих маршрутизаторов указан не ip адрес nexthop'а (интерфейс соседа), а выходной интерфейс самого маршрутизатора.
Найдя полученный опыт полезным для усвоения основ различий в работе протоколов 2 уровня, я решил им поделиться с другими начинающими
Схема для тестирования была не долго думая собрана в Packet-Tracer'e от дорогой, любимой Cisco, настроена и обкатана с прескорбным результатом — пинги не ходят, как маршруты ни пиши. Казалось бы, всё понятно — адреса то разные, вот маршрутизатор и не узнаёт того, к кому я его сватаю. С другой стороны, таблица маршрутизации заполнена предельно чётко — бери и отправляй, в чём проблема?
Явный и ясный ответ помог найти режим Simulation, доступный в Packet Tracer'e, который по пакетам и уровням показывает, что же у вас на сети происходят, как куда ходят фреймы и пакеты. И выяснил я для себя (а точнее, уяснил на практике уже изученное ранее по тому же Odom'у) следующее: что не работает на Ethernet, работает на HDLC.
Теперь перейдём к
Так выглядит схема с таблицами маршуртизации
У маршрутизаторов идентичные настройки (буковки слева выведены для маршрутизатора HDLC-R1, на маршрутизаторе EthernetR1 в конфигурации вместо интерфейса Serial 0/1/0 будет gigabitEthernet 0/0; аналогично и симметрично для правых маршрутизаторов).
Настройки, применявшиеся на маршрутизаторах:
HDLC-R1:
(conf)# interface serial 0/1/0 (gig 0/0 для примера Ethernet, соответственно)
(conf-if)# ip address 192.168.1.1 255.255.255.0
(conf-if)# no shutdown
(conf)# interface loopback 0
(conf-if)# ip address 10.1.1.1 255.255.255.255
(conf)# ip route 172.16.0.0 255.255.0.0 serial 0/1/0
(conf)# ip route 10.2.1.1 255.255.255.255 serial 0/1/0HDLC-R2:
(conf)# interface serial 0/1/0 (gig 0/0 для примера Ethernet, соответственно)
(conf-if)# ip address 172.16.0.1 255.255.0.0
(conf-if)# no shutdown
(conf)# interface loopback 0
(conf-if)# ip address 10.2.1.1 255.255.255.255
(conf)# ip route 192.168.1.0 255.255.255.0 serial 0/1/0
(conf)# ip route 10.1.1.1 255.255.255.255 serial 0/1/0При попытке отправить пинг по Ethernet, маршрутизатор находит соответствие в таблице маршрутизации (при этом сначала маршрутизатор ищет соответствие в CEF-таблице, см. англоязычные рисунки ниже). Далее маршрутизатор запаковывает ICMP Echo Request в IP, указывая source и destination ip, и переходит к взаимодействию на втором уровне, собирая frame. Маршрутизатор в ARP Таблице не находит соответствие IP адреса и MAC адреса получателя (т.к. Ethernet — не point-to-point подключение, т.е. на другом конце может быть много железа, и маршрутизатор таки должен понимать — кому же всё-таки отправлять
В связи с этим, маршрутизатор отправляет широковещательный ARP запрос, запаковав его в Ethernet frame c broadcast адресом FFFF:FFFF:FFFF.
Сосед получает L2 frame (Ethernet). Смотрит MAC адрес destination — видит, что это broadcast. Декапсулирует ethernet frame — находит там ARP запрос. При этом запрос прислали с source IP, который находится в другой подсети, нежели порт маршрутизатора, на который frame с ARP пришёл. Маршрутизатор отбрасывает этот пакет = пинга нет.
На Serail линке с протоколом HDLC, работающим на втором уровне, такого не происходит! Получатель принимает приходящий на порт пакет, молча распаковывает его (снимает заголовок HDLC), видит там свои IP адреса и отлично всё маршрутизирует в любую известную ему точку = отвечает на наш ping. Почему так происходит? HDLC, будучи P2P (point-to-point, точка-точка) протоколом, не оперирует MAC-адресами! Если мы выведем ARP таблицу для маршрутизаторов, подключенных серийными кабелями, они будут пусты несмотря на то, что связность между узлами есть (слева вывод для маршрутизаторов, подключенных по serial, справа — по ethernet) Заметьте, там, где ethernet, МАС-адреса соседа нету! Наш маршрутизатор EthernetR1 с ним так и не познакомился.
Для сравнения, frame HDLC:
И frame Ethernet с запросом ARP из рассматриваемого примера:
Таким образом, просто указав физический порт маршрутизатора, с которого доступен получатель, при использовании на L2 технологии Ethernet, нельзя получить удовлетворительного результата — маршрутизатор не выкинет с указанного интерфейса frame, т.к. не знает, на какой MAC его отправить, а broadcast'ом по L2 пакет unicast уровня L3 тоже отправлять никак нельзя.
Подводя итог — учите матчасть, ни в коем случае не ограничивайтесь теорией, даже если она кажется очень простой при прочтении. Пробуйте всё руками, задавайте сами себе вопросы и ищите на них ответы как при помощи своей головы/рук, так и пользуясь помощью более опытных товарищей, интернета, книг.
Всем спасибо!