Настройка IP-адресов и маршрутизации на устройствах Cisco

Продолжаем разговор по курсу ACND1. Мы с вами прошли теорию про IP, посмотрели, что такое IP в целом, как маршрутизируются IP-пакеты. И давайте посмотрим на примере Cisco IOS, как настраивается IP на маршрутизаторах и на коммутаторах тоже цисковских. Посмотрим на то, что там есть поковырять. Начнём со следующего очевидного факта. Для того чтобы работать с IP, вам потребуются IP-адреса. И вы эти адреса должны будете назначать на интерфейсы в соответствии с тем, что мы с вами уже прошли. Для того чтобы назначить IP-адрес, вам потребуется интерфейс, который способен работать с IP-пакетами, приходящими в какой-то инкапсуляции на канальном уровне. Причём вы должны уметь эти пакеты обрабатывать. Если у вас есть физический интерфейс, который смотрит в какую-то канальную среду, то вы можете прямо на этот интерфейс циски назначить IP-адрес.

Если у вас есть какой-то виртуальный интерфейс, вы можете назначить адрес на него. Это может быть туннель, это может быть так называемый SVI. Встречается на свитчах, и смысл у SVI будет следующий. Есть у вас свитч. У него есть, как мы уже смотрели, на цисках несколько разных виртуальных свитчей, которые обслуживают разных пользователей. Вот этот свитч VLAN 1, вот этот свитч VLAN 2, виртуальный свитч, как виртуальные машины, запущенные на большом физическом гипервизоре. И некоторые интерфейсы у нас будут соединены с этими самыми виртуальными свитчами. На физических интерфейсах свитчей нету MAC-адресов. Здесь нет MAC-адреса, и здесь тоже нет MAC-адреса своего. Если вдруг вы хотите отправлять или принимать какие-то кадры в Ethernet, вам потребуется какой-то MAC-адрес, и он должен висеть на вашем устройстве, но не на физическом интерфейсе. И для того чтобы это происходило, вам потребуется, условно говоря,

виртуальный, если хотите, компьютер, который будет также запущен в виде виртуальной машины на вашем свитче, который будет подключаться к одному из виртуальных коммутаторов. И вот этот виртуальный компьютер и будет называться SVI. Switch Virtual Interface. На него вы можете повесить IP-адрес, потому что у него есть свой собственный MAC, у него есть возможность использовать IP-адрес, он может отправлять пакет, он может принимать пакет, он их может формировать. Виртуальные свитчи сами ничего не формируют, сами ничего не отправляют. И физические интерфейсы тоже на свитчах ничего нового не отправляют, ничего сами не принимают. Они только нужны для коммутации чужого транзитного трафика. И если вы на свитче хотите создать такой виртуальный интерфейс SVI, то вы должны воспользоваться следующей конструкцией. Interface. Дальше указываете VLAN и номер VLAN. Это не указывает на то, что у вас есть этот VLAN.

Вы должны отдельно создать сам VLAN в базе, VLAN 10. Вы тем самым создаёте виртуальный коммутатор 10-го VLAN. И отдельно вы создаёте interface VLAN 10. Это тот самый SVI, на который можно повесить IP-адрес. И уже на него вешаете IP-адрес. IP address 192.168.1.2 по маске 255.255.255.0. Циски до сих пор не позволяют на интерфейсе вешать IP-адреса с указанием префиксной записи маски. 2019 год. Вы в 2019 году должны указывать 255.255.255.0. Если у вас роутер, то этих действий создания виртуального интерфейса можно избежать. У вас на интерфейсах роутеров уже штатно есть MAC-адрес. Эти интерфейсы могут штатно отправлять, принимать кадры. Эти кадры могут содержать IP-пакеты. Вы прямо на самом интерфейсе можете выполнить команду

ip address и дальше назначить IP-адрес на этом интерфейсе. На свитче сразу на железном интерфейсе GigabitEthernet 0/0 у вас не получится повесить IP-адрес. Система просто скажет, что нет такой команды. И действительно, на свитче все интерфейсы, как правило, находятся в коммутирующем режиме. Если мы используем терминологию Cisco, это интерфейсы switchport. Они занимаются коммутацией чужого трафика. Те кадры, которые приходят на этот интерфейс, направляются на коммутацию по таблице коммутации. Дальше они куда-то там деваются. На таких switchport-интерфейсах нет MAC-адресов. Кадры, которые приходят, они обязательно уходят дальше куда-то в транзит. На роутерах MAC-адреса есть. Если кадр приходит на роутерный интерфейс на этот MAC-адрес, он обрабатывается. Если кадр приходит на любой другой MAC-адрес, он отбрасывается и игнорируется. Наш роутер зажмурится и кадры на другие MAC-адреса читать не будет. В этом заключается разница между коммутируемыми интерфейсами, или в терминологии Cisco switchport, или

такие интерфейсы ещё называют L2, и маршрутизируемым интерфейсом. Он будет роутерным интерфейсом, или no switchport, или их иногда ещё называют L3. Почему их называют L2 и L3? Именно потому, что поведение интерфейса в части кадров будет различаться. Здесь мы встречаем использование этих самых номеров уровней L2 и L3. Здесь, наверное, придётся немножко покопаться в истории, вспомнить модель OSI, вспомнить, что у нас обозначают эти уровни, и попытаться понять, какое отношение L2 и L3 имеют конкретно к этому случаю. L2, или Layer 2, в уровневой модели OSI — это у нас канальный уровень, который отвечает за упорядочивание битовых последовательностей для составления кадра. Отвечает за формирование, за передачу каких-то кадров в пределах общего провода.

А L3 — это у нас операция сетевого уровня, это перекладывание пакетов между проводами, для того чтобы пакет в итоге дошёл до получателя. Сначала между одной парой проводов он перекладывается одним устройством, потом другое устройство между другой парой проводов всё перекладывает, или более строго между каналами, и так далее, пока всё не дотягивается до получателя. Вообще говоря, любой коммутатор — это устройство, которое выполняет операцию третьего уровня в модели OSI. Но почему мы говорим, что бывают коммутаторы, которые называются L2-коммутатор, и коммутаторы, которые называются L3-коммутаторы? Дело в том, что если у нас есть коммутатор, который выполняет только операцию коммутации и больше ничего, то у нас получается железный коммутатор. У него есть какие-то виртуальные коммутаторы, которые на нём созданы. И эти виртуальные коммутаторы обслуживают виртуальные широковещательные домены, которые никак между собой не связаны. Они изолированы. И у нас есть, допустим, два интерфейса, которые относятся к VLAN, допустим, 10-му, и 20-му —

тоже два интерфейса. Они соединены с этими виртуальными коммутаторами. Получается отдельный широковещательный домен, обособленный, 10-го VLAN, и отдельный широковещательный домен, точно так же обособленный, 20-го VLAN. Они никак между собой не связаны, нельзя отправить трафик между 10-м и 20-м VLAN. Фактически этот большой коммутатор прикидывается двумя толстыми жёлтыми коаксиалами. Он говорит: я всё равно что первый коаксиал и второй коаксиал. Невозможно определить наличие этого коммутатора в транзите между двумя узлами, которые находятся в одном и том же VLAN. Вы не можете определить по внешнему виду провода, есть там коммутатор или нет. Вы можете только предположить, что он там есть. Но даже если вы догадываетесь, что он там есть, вы совершенно точно не можете определить, сколько этих коммутаторов. С точки зрения абонента, первого абонента и второго абонента, они соединены проводом. Есть в этом проводе коммутатор или нет?

Невозможно определить. Вот такая ситуация. У вас два интерфейса, они находятся в полнодуплексном режиме, просто два узла связаны прямым проводом. Или же здесь есть транзитный коммутатор. Тоже два интерфейса, они точно так же связаны прямым проводом. Есть коммутатор или нет с точки зрения узлов? Невозможно понять, потому что коммутатор максимально эффективно прикидывается тем, что его там нету. Он старается не отсвечивать, старается быть прозрачным. Или может быть там вообще два коммутатора или три коммутатора. Невозможно в Ethernet определить, есть коммутатор в сети или нет. Если у вас коммутатор в таком режиме работает, он пытается прикидываться толстым жёлтым коаксиалом, он пытается сэмулировать один общий широковещательный домен. В этом случае такие коммутаторы называются словом L2. Или, скажем, они работают в режиме эмуляции одного большого провода. Это эмуляция одного большого широковещательного домена. Если же у вас есть коммутатор, который не пытается прикинуться одним шлангом,

он говорит: да, у меня два шланга, и да, у меня ещё есть виртуальный маршрутизатор, который на мне запущен, который связывает между собой эти два шланга. С точки зрения абонентов получается, что два виртуальных коаксиала, два виртуальных широковещательных домена и маршрутизатор, который их между собой связывает. Узлы видят этот маршрутизатор, они знают, что у него есть MAC-адрес, они на этот MAC-адрес будут посылать кадры, которые будут предназначены для маршрутизации куда-то дальше в сеть назначения. Такой коммутатор будет называться словом L3-коммутатор. Он не пытается проэмулировать толстый жёлтый коаксиал так, чтобы вообще никто не догадался, что этот коммутатор в сети существует. Он раскрывает себя, он говорит: да, я эмулирую несколько виртуальных проводов, несколько широковещательных доменов и маршрутизатор между ними. И в этом случае он пытается задекларировать тот факт, что он занимается перекладыванием кадров между интерфейсами. Любой коммутатор

занимается перекладыванием кадров между интерфейсами, но один коммутатор пытается это скрыть, а другой коммутатор это скрыть не пытается. Тот, который пытается это скрыть, называется L2, тот, который не пытается это скрыть, называется L3. В случае если у нас есть коммутатор, который скрывает то, что он занимается перекладыванием кадров между интерфейсами, пытается прикидываться просто общим широковещательным доменом, общим коаксиалом, у него порты будут называться портами L2. Это коммутирующие порты, трафик приходит на порт и уходит с одного или нескольких других портов сообразно таблице коммутации. По общему правилу разбрасываем всё по всем портам, кроме некоторых. В случае если у нас есть порт, который работает в маршрутизирующем режиме, или в L3-режиме, у этого порта поведение меняется. На этом порту у нас есть собственный MAC-адрес. Кадры, которые приходят на этот MAC, мы обрабатываем. Причём мы их не коммутируем. Мы их читаем, открываем, смотрим, что внутри лежит. И уже содержимое мы дальше как-то обрабатываем сообразно,

например, таблице маршрутизации. А кадры, которые приходят на другие MAC, не наши собственные, мы просто игнорируем и никак не обрабатываем. В этом разница между L2 и L3 интерфейсами. Может быть такое, что у вас на свитче можно переключить интерфейс из режима L2 в L3. Может быть такое, что у вас есть некий интерфейс на свитче, подчеркну, и вы его переключаете, говорите: это будет L3-интерфейс. У вас на нём появляется MAC. Вы на него можете повесить IP-адрес. И кадры, которые будут приходить на этот интерфейс, они не будут направляться на таблицу коммутации. Они будут направляться напрямую на интерфейс маршрутизатора, который у вас будет на этом свитче. Но мы про это говорим в отдельном модуле на курсе по свитчингу. В любом случае, если у вас есть интерфейс, на котором есть свой собственный адрес, На него можно повесить IP-шник. Вы можете посмотреть настройки IP на интерфейсе. Есть команда show IP interfaces, дальше название интерфейса.

В принципе, есть просто show IP interfaces. Она покажет большую простыню по всем интерфейсам, которые у вас в системе есть. Допустим, у вас есть роутер, у него там мало интерфейсов. Но если у вас, например, свитч, на котором, например, 48 интерфейсов, вы делаете show IP interfaces, и он вам по всем 48 интерфейсам будет рассказывать, в том числе то, что вы не можете включить IP на каждом из этих интерфейсов. Короче говоря, то ещё удовольствие. Поэтому по факту show IP interfaces, и дальше вы указываете интерфейс. Эта команда показывает настройки IP на каждом вашем интерфейсе. Первая строчка дублируется с show interfaces, она просто показывает, интерфейс в UP или нет. Дальше показывается IP-шник, и ещё рассказывается, откуда он взялся. В нашем случае он взялся, потому что его кто-то проадминил и ручками повесил. Ещё, например, можно получить адрес по DHCP, может быть такое, что вам его назначат внутри VPN-туннеля по протоколу PPP, или каким-то иным образом. Либо ручками, либо динамически мы его получаем.

Дальше показывается широковещательный адрес, который вы используете. Здесь показывается только так называемый local broadcast. Но на самом деле ещё, конечно же, есть и directed broadcast. Если у вас 192.168.1.1 по 24-й маске IP-шник, то 192.168.1.0 — это network ID. И дальше все биты host ID мы объединичиваем, и получаем 255. Это широковещательный адрес, к которому присоединяется узел по факту назначения IP-шника 192.168.1.1 по 24-й маске. Показывается MTU, Maximum Transmission Unit. IP-пакеты какого размера вы на этом интерфейсе можете отправлять или принимать. На самом деле принимать IP-пакеты вы можете здесь любые. Если интерфейс способен принимать IP-пакеты большего размера, никаких проблем, вы их примете. Но отправлять вы будете пакеты не больше, чем 1,5 килобайта. Если вы будете пытаться отправлять в этот интерфейс на роутере

пакеты больше, чем 1,5 килобайта, роутер ваш будет заниматься фрагментацией, если это не запрещено настройками пакета. Вот этой командой show IP interface и дальше название интерфейса удобно заниматься траблшутингом. Когда у вас есть какая-то проблема, и вы не уверены, как настроен ваш IP на интерфейсе, тогда удобно эту команду выполнить, и она сразу всё рассказывает. В то же время, если вы хотите просто сводную табличку получить, в которой посмотреть, какие у вас IP-шники есть, откуда они взялись на всех интерфейсах, удобнее смотреть show IP interface brief, и тогда вам покажут табличку, все интерфейсы перечислят, на которых IP может быть назначен, покажут IP-шник, который висит, основной, и покажут, откуда взялся этот IP-шник и в каком состоянии находится интерфейс. В большинстве ситуаций show IP interface brief — это достаточно удобная команда, и именно ей чаще всего мы будем пользоваться. По факту назначения IP-адреса на интерфейсе, неважно, откуда он взялся, если у вас есть IP-шник на интерфейсе,

у вас появляется запись в таблице маршрутизации. На Cisco таблица маршрутизации отображается командой show IP route, и вы можете видеть эту самую таблицу. Вот это — легенда, она нас сейчас не сильно интересует, а вот это — таблица. И мы здесь видим, что у нас есть сетка 192.168.1.0 по 24-й маске. Это классовая сеть, это сеть класса C. И она в variable subnet, у нас есть в таблице маршрутизации кусочки этой сети, которые имеют разные маски. И нам говорят, что у нас есть две различные маски, которые в таблице маршрутизации будут присутствовать. Вот это явление, что мы повесили один IP-шник на интерфейс, а у нас появляются две строчки в таблице маршрутизации, причём с разными масками — оно появилось в 15-м IOS, в 12-м такого не было, но оно будет нужно для удобства работы аппаратного ускорителя. И это поведение будет заключаться

в следующем. У вас появляется автоматически так называемая connected-сетка. Она обозначается буквой C в табличке и показывается: 192.168.1.0 по 24-й маске у вас connected или directly connected на интерфейсе GigabitEthernet 0/0. Это автоматически происходит, когда вы назначаете адрес 192.168.1.1 /24 на интерфейсе. Этот адрес принадлежит сети 192.168.1.0 по 24-й маске, и она появляется как connected-сетка. Вторая строчка будет иметь тип L. Если мы найдём здесь L, мы увидим, что это так называемый локальный маршрут. Это ваш собственный IP-шник 192.168.1.1 по 32-й маске. Он визуально точно так же выглядит, точно так же connected, точно так же GigabitEthernet 0/0. Но этот IP-шник, ваш собственный, он будет в таблице маршрутизации нужен для решения следующей задачи.

Если у нас есть роутер, у него есть два интерфейса, левый и правый. На этом интерфейсе висит IP-шник 10.0.1.1 по 24-й маске. Здесь у нас висит 10.0.2.1, тоже по 24-й маске. Везде, если не указано иное, будет 24-я маска. И к нам приходит пакет, у которого destination-адрес указан 10.0.2.1. Пакет приходит на этом интерфейсе. Cisco проверяет, на какой IP-шник идёт пакет, не на тот ли IP-шник, который висит на самом интерфейсе. Видит — нет, IP-шники не совпадают. Она говорит: окей, запускаем движок маршрутизации. И дальше движок маршрутизации должен найти выходной интерфейс. И для случая, когда таблица маршрутизации должна определить, что выходной интерфейс для конкретного пакета должен быть не интерфейсом, а этот пакет на самом деле предназначен именно нам, есть специальная отдельная строчка с этим локальным маршрутом. Фишка в том, чтобы выделить свои собственные пакеты

из всех остальных адресов, которые у нас есть на интерфейсе, которые надо направить действительно в этот интерфейс. Дело в том, что если этого маршрута не было, то пакеты, которые на наш роутер пришли бы, и они были бы предназначены для IP-шника 192.168.1.1, таблица маршрутизации сказала бы: это адрес, который надо направить в сторону GigabitEthernet 0/0, и мы бы пытались в сторону этого интерфейса отправить пакеты на адрес 192.168.1.1, то есть на наш собственный адрес. Мы бы пытались их действительно отправить физически в интерфейс. А это не нужно, потому что этот адрес наш собственный, и естественно, что на наш собственный IP-шник бесполезно пытаться направить пакеты в интерфейс к какому-то соседу. Нет таких соседей, у которых есть наш собственный IP-шник. Поэтому специальное правило по принципу longest prefix match, или наиболее специфичного маршрута, говорит, что вся сетка 192.168.1.0 по 24-й маске доступна за интерфейсом, а именно 192.168.1.1

по 32-й маске, то есть именно IP-шник 192.168.1.1, недоступен за этим интерфейсом. Если срабатывает этот локальный маршрут, то такой пакет не надо отправлять на интерфейс, надо его отправить на центральный процессор роутера. Это такой специальный лайфхак, как упростить обработку своих собственных пакетов. Он будет нужен для работы аппаратного ускорителя, про который мы будем говорить на курсе по свитчам. Вы можете повесить IP-адрес на интерфейс, и у вас автоматически появится по факту назначения адреса connected-маршрут. И даже локальный маршрут тоже автоматически появится. Иногда хочется рассказать роутеру, что существуют какие-то другие сети, кроме тех, к которым мы непосредственно подключены. Это может быть маршрут до какой-то сети, которая доступна через соседний роутер, или что-то ещё. И в этом случае маршруты могут указывать на соседей,

и мы должны будем указать либо через какой интерфейс будет доступен некий маршрут, либо через какого соседа будет доступен некий маршрут. Такие маршруты мы можем добавить ручками, и тогда они будут называться словом static. И буковка у них будет показываться S. Для того чтобы добавить статический маршрут, мы должны будем указать команду ip route в конфиге. Дальше указываем IP-шник сети и маску. Причём важно то, что если у вас с учётом этой маски некоторые биты host ID этого IP-шника не будут выставлены в ноль, система будет ругаться и говорить: ты мне пытаешься подсунуть кривой адрес, это не может быть адресом сети. Вы должны будете убедиться, если вдруг вы пытаетесь ip route указать, а она говорит «неправильный IP-адрес», что ваше указание IP-шника сети с указанием маски действительно соответствует адресу сети. Совершенно неправильно будет пытаться добавить ip route 192.168.2.1 по маске 255.255.255.0,

потому что 192.168.2.1 по 24-й маске это не IP-адрес сети. Вы должны указывать именно IP-адрес сети, маску, которая указывает на то, где проходит граница между левой и правой частью этого адреса, и Cisco проверяет, что хост-айди там будет нулевой. И дальше вы должны указать IP-шник шлюза, через который будет доступна ваша сеть. Соответственно, может быть такое, что вы будете добавлять статические маршруты, будете иногда автоматически получать какие-то маршруты от соседних роутеров, и эти все маршруты, они будут обозначаться всякими разными буквами. Вот S — это как раз статический маршрут, который админ ручками вбил. R — это динамический маршрут, который вы получили по протоколу RIP. O — это маршрут, который вы получили по SPF. Допустим, B — это BGP. Ну, D — это EGRP и так далее. Со всем этим мы будем обязательно сталкиваться дальше. Если вы добавляете статический маршрут, то вы, как администратор, говорите, что вот вы

точно указываете, как добраться до некоторой сети, и, соответственно, вы указываете, в каком направлении пакеты надо отправить так, чтобы они дошли до кого-то, кто находится ближе к получателю, чем вы. вы должны указать именно на маршрутизатор, который соседний с вами и который может отправить трафик до получателя. Формат этой команды, соответственно, IP-road, сетка IP-шник сети, маска для этого IP-шника и IP-шник шлюза. По большому счету, на самом деле, мы, когда отправляем пакеты, мы нигде IP-шник шлюза не указываем. Мы должны будем IP-шник указать только для решения одной единственной задачи. Для того, чтобы определить, в каком интерфейсе эта сетка на самом деле будет находиться. Где взять того соседа за каким интерфейсом, который находится ближе к получателю, чем мы. И от этого соседа при необходимости мы возьмем канальный адрес каким-то образом. То есть, если у нас есть, опять же, роутер,

у него есть роутер с одной стороны, роутер с другой стороны, вот возникает вопрос, куда отправить пакет? Сюда, сюда, или если у нас есть, допустим, какой-то еще тут свитч, и в этом свитче у нас два соседа. Вот возникает вопрос. Если мы сюда, допустим, хотим отправить, то должно пойти в итоге на одного соседа или на другого? То есть, кому конкретно мы отправим этот пакет до кого из соседей, если там соседей несколько? И поэтому, когда мы указываем IP-шник шлюза, мы как раз определяем однозначно того самого соседа, мы говорим, вот на этот вот интерфейс, на этого вот соседа мы отправляем трафик. И по факту, от IP-шника шлюза, если мы указываем IP-шник шлюза, берется только его канальный адрес, например, MAC-адрес, если мы говорим про Ethernet. В некоторых типах интерфейсов канального адреса может не быть. То есть, это будет нормальная ситуация, мы в ICND2 разберем такие случаи. Может быть такое, что канальный адрес будет совсем не MAC-адрес.

В некоторых типах интерфейсов это будет абсолютно нормальное явление. Например, во Frame Relay у нас MAC-адресов нету. Канальные адреса есть, а MAC-ов нет. Потому что там канальные адреса называются по-другому. Они называются DLCI, и у них даже смысл другой. Но, да, если вдруг вам интересно, вот у нас там есть про Frame Relay отдельное видео на нашем канале и на сайте выложено. Можете посмотреть. Далее. Вы можете указать для маршрута шлюз не в виде IP-адреса. Это надо делать с очень большой осторожностью и допустимо это делать в ситуации, когда у вас сосед находится за Point-to-Point канала. В том случае, если у вас ровно один узел может находиться в канальной среде, не по факту находится, а именно может находиться в канальной среде, вы можете не указывать в IP-шню. Например, у вас есть VPN-туннель. Два роутера связаны между собой VPN-туннелем.

Все, то, что вы отправите в туннель, по определению просто гарантированно может пройти только до другого конца туннеля. Оно не может уйти куда-либо еще. В туннеле у вас по определению ровно один сосед находится. Поэтому вы можете там не указывать адрес соседа. Но, например, если вы возьмете Ethernet, вот у нас есть роутер, другой роутер, и они связаны между собой патч-кордом. И вот мы говорим, у нас в Ethernet по факту, вот мы глазками видим, ровно один сосед. Но гипотетически никто не может предсказать, что на самом деле там не находится коммутатор в разрыве между двумя роутерами. И не возьмется там какой-нибудь еще другой узел. Или третий, или четвертый. Поэтому мы не можем точно быть уверены, что в Ethernet всегда ровно один сосед у нас будет находиться. Поэтому, если мы работаем по Ethernet, то мы всегда должны будем указывать IP-шник соседа, на который мы отправляем трафик. И от него будет браться по факту MAC-адрес. Допустим, AA, BB,

CC, 0, 0, там, ну, какой-то MAC-адрес. И по факту именно на этот MAC-адрес мы будем посылать кадры, содержащие IP-пакеты, которые тот сосед должен передать дальше в сторону следующего роутера в цепочке. И так по цепочке этот пакет должен дойти до получателя. Если ваша канальная среда гипотетически предполагает взаимодействие больше, чем двух участников, например, Ethernet, то вы фактически обязаны указывать IP-шник. И формат команды будет именно такой. IP-роут, IP-шник, маска, шлюз. Если вы сидите за интерфейсом, который имеет тип среды point-to-point, и он гипотетически даже не допускает существования больше двух участников, например, это PPP-шный туннель, или, например, это Serial Link, ну, там, да, с HDLC каким-нибудь, HDLC. Или это какой-то, не знаю, ATM point-to-point subinterface, или это Frame Relays point-to-point subinterface.

То есть, это такая среда, в которой у вас, в принципе, невозможно взаимодействие больше, чем двух участников. Гипотетически невозможно. В этом случае вы можете указать только название интерфейса. И канальный адрес соседа в этом случае не нужен, поэтому IP-шник тоже можно не указывать. Если вы ошибетесь и добавите маршрут на мультиаксесс-сетку типа Ethernet, и укажете там формат команды IP-шник маска и интерфейс, но не укажете IP-шник шлюза, это может привести к проблемам, причем к очень большим проблемам, поэтому так делать не рекомендуется, решительно не рекомендуется. Проблемы там могут быть довольно серьезные. Так, и что еще про маршруты статические хотелось бы добавить. Вы можете добавить несколько маршрутов до одной и той же сети. То есть вы можете написать две команды IP-road, дальше 10.1.0.0 по маске 255.255.0.0 и дальше указать один маршрут

и точно так же рядом указать другой маршрут. Это будет работать одновременно. То есть у вас все маршруты одновременно добавятся в таблицу маршрутизации. И вот в такой вот ситуации у нас часть трафика пойдет на сериал 1.0 часть трафика пойдет на тоннель 0. Они оба эти маршрута будут работать одновременно. Если вдруг вы хотите, чтобы у вас работал только один маршрут, вы должны будете сначала удалить старый, а потом добавить новый. Удавление маршрута происходит с помощью команды no и дальше ту самую команду, которую вы добавили маршрут, вы пишете целиком no.iproad 10.100, 10.55, 10.55, 10.55, 10.55, 10.55, 10.55, 10.55, 10.1. Вот. Вот такая вот особенность, что да, у вас может быть такое, что два маршрута вы добавите ручками, и они будут работать одновременно. В некоторых других операционных системах, не цисковских, такое сделать нельзя. То есть у вас всегда будет работать только один маршрут, а второй, например, будет запасной, он будет как неактивный. В цисках все маршруты, которые вы добавили, которые имеют одинаковый тип, одинаковые

ip-шники к сети, одинаковую маску, просто они смотрят в разные стороны, они все будут работать одновременно. Часть трафика будет идти по одному маршруту, часть по другому. Так, мы молодцы, мы посмотрели на то, как работает цисковский IP. Я предлагаю сейчас лабу на это не делать, потому что там вся лаба-то это просто ip-шник назначить и маршрут поднять. Но я предлагаю сейчас немножко оттянуть все это дело, дождаться следующей темы. и там уже сделать совокупную лабораторную работу на все это дело.