Работа с канальными средами в Cisco IOS (часть 1)

Давайте разбираться с настройкой каналов в Cisco. Первое, что надо будет вспомнить, это настройка Ethernet. Здесь достаточно всё предсказуемо-тривиально. Если у нас есть интерфейс Ethernet, на нём единственное, что можно сделать, это фактически MAC-адрес поменять и MTU поправить. С MTU история следующая на Cisco. Такого термина, как MTU, в Ethernet нет. Термин MTU есть в IP. И если вы хотите, вы можете менять максимальный размер IP-пакета, который у вас получится, если вы отправляете IP-пакеты. Но если вы вкладываете IP-пакеты в Ethernet, то если вы делаете IP-пакеты большего, чем, например, 1500 байт размера, то вы должны будете и Ethernet-кадры разрешить делать большего размера.

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

А вы будете задавать только размер MAC Client Data. То есть размер того, что вы можете положить внутрь этого кадра. И вот эта команда в настройке интерфейса, MTU чего-нибудь, она указывает размер содержимого, которое вы можете в кадр поместить. Причём содержимого именно в интерпретации Ethernet II, когда вы вкладываете IP-пакеты и указываете в EtherType соответствующее значение. Это поле MTU — это не MTU, потому что в Ethernet нет MTU. Нет такого термина L2-MTU. В Ethernet вообще такой аббревиатуры нет. И такого термина нет. Но вы указываете в этом поле то, сколько вы можете положить внутрь полезных данных. Соответственно, если вы указываете MTU 1500, то вы тем самым говорите: в кадр Ethernet я могу положить 1500 байт полезных данных. И, например, эти 1500 байт прекрасно в себя вместят нормальный IP-пакет, который тоже в норме может быть до 1500 байт размером.

Если вы хотите, вы можете сказать: MTU у нас должен быть побольше, например, 10 килобайт. Пожалуйста. Команда MTU 10240 на самом деле поменяет размер содержимого в Ethernet, который мы можем передавать. Плюс отдельно будут заголовки Ethernet, плюс отдельно будет чек-сумма. И они здесь не считаются. Есть ещё одна засада, которая здесь вас поджидает. Некоторые заголовки, которые вы будете добавлять к полезным данным, Cisco сама здесь может посчитать. Например, если вы включаете на интерфейсе 802.1Q инкапсуляцию, то есть будете помечать дополнительно 802.1Q заголовком, в каком VLAN кадр передаётся, то этот механизм добавляет 4 байта к заголовку Ethernet. Эти 4 байта 802.1Q не включаются в байты, которые вы указываете командой MTU.

Размер содержимого вы указываете, а дополнительные заголовки Ethernet — нет, и они автоматически «бесплатно» прибавляются. Указывая MTU, например, 1500, по факту вы говорите, что есть 1500 байт данных, плюс 14 байт стандартный заголовок Ethernet, плюс, возможно, 4 байта 802.1Q, плюс 4 байта чек-суммы. Всё это для вас получается «бесплатно». Но засада заключается в том, что Cisco знает только про некоторые заголовки, которые должны для вас оказываться бесплатными. Например, про один заголовок 802.1Q она знает. Поэтому, если вы хотите добавлять один заголовок 802.1Q, то вы можете его здесь не указывать. Но если вы хотите добавлять два заголовка 802.1Q — а эта штука будет встречаться у провайдеров и называется Q-in-Q, когда вы две метки 802.1Q подряд ставите, — то вторую Cisco уже вам не посчитает.

Вы должны будете сами запланировать под неё место. Если вы знаете, что у вас 1500-байтовые IP-пакеты идут, то вы должны к этим 1500 байтам ещё дополнительно 4 байта на дополнительную 802.1Q метку добавить, которую Cisco сама посчитать не сможет, потому что этих меток будет две. Она одну посчитает, а вторую уже нет. И вы тогда должны будете сказать MTU 1504. В той логике, что 1500 байт под IP-пакет и ещё 4 байта под 802.1Q заголовок. Или, например, MPLS вы захотите использовать. Та же самая история: если вы хотите через интерфейс посылать MPLS-пакеты, метки MPLS тоже занимают 4 байта. И Cisco их не учитывает. Вы должны будете сами их посчитать. Вы должны будете сказать, что если мы одну метку добавляем, то MTU должно быть 1504. Для двух меток — 1508. Три — 1512 и так далее. Поэтому здесь надо просто помнить список дополнительных заголовков, которые Cisco вам бесплатно добавляет к байтам, которые вы указываете в команде MTU.

Это одна метка 802.1Q. Сами заголовки Ethernet здесь не учитываются. Чек-сумма Ethernet не учитывается. Всё остальное считается, что оно вкладывается в MAC Client Data. И вы должны будете, если вдруг вы используете какие-то дополнительные заголовки, помимо максимального размера пакета, который вы будете передавать, дополнительно прибавить все эти заголовки, которые вы хотите добавлять. И максимальную сумму, которая может получиться, указывать в команде MTU. Абсолютно дурацкая концепция, которая приводит к тому, что здесь добавляем, здесь не добавляем, здесь помним, что Cisco про это знает, здесь помним, что Cisco про это не знает.

Поэтому проще всего просто задавать размер содержимого кадров Ethernet заведомо больше, чем у вас кадры могут получиться. Это будет в большинстве ситуаций достаточно для ваших задач. Дальше. На коммутаторах ситуация другая. Эта команда MTU чего-нибудь есть на маршрутизаторах. И эта команда задаёт максимальный размер содержимого кадра плюс ещё фиксированные заголовки, которые в Ethernet есть. Фактически она задаёт максимальный размер кадра, который мы имеем право отправлять. И, что важно, принимать. Эта команда, с одной стороны, скажет, какого размера кадры мы отправляем, но это для нас не сильно интересно. Что для нас интересно — она не позволит принять кадр с содержимым большего размера. Если вдруг у вас есть интерфейс, и на этом интерфейсе начинают приходить биты, вы эти биты слушаете и считаете.

И если вы послушали, что на интерфейсе пришло уже 16 тысяч бит или 2000 байт, вы говорите: это уже точно заведомо битый кадр. Не может такого быть, чтобы на интерфейсе, на котором у нас MTU 1500, кадр пришёл размером 2000 байт. Поэтому если вдруг у вас кадр придёт с размером большим, чем задано в этой команде, опосредованно задано, то такие кадры будут отбрасываться с указанием, что этот кадр — переросток, кадр гигантского размера. И у вас, если вы посмотрите в show interface на роутерах, есть счётчики ошибок. И один из счётчиков будет называться giants. Это как раз такие кадры, которые размером больше, чем допустимый максимальный размер, заданный в команде MTU. Кстати, есть ещё и другая крайность. Это кадры размера меньшего, чем минимально возможный. Меньше, чем 64 байта, включая заголовки. Такие кадры называют runts. Огрызки.

Так, с коммутаторами. На коммутаторах, как правило, команды MTU на интерфейсах нет. Вы не можете, как правило, на коммутаторах менять MTU на отдельном интерфейсе. Но вы можете менять MTU на уровне матрицы коммутации. Вы просто скажете, что все кадры, которые наш свитч может через себя пропускать, должны иметь какое-то одно общее ограничение. И команда будет system mtu. Если говорить про младшие линейки, то она как раз и задаётся. На старших коммутаторах — Catalyst 4000, 6000 — есть MTU на интерфейсах. Но на младших моделях, типа 2960, 3750, 3850, есть только system mtu. Можно использовать system mtu и просто записать 1500. И тем самым вы зададите максимальный размер кадра на 10/100-мегабитных интерфейсах. Просто system mtu и цифра — это только 10/100 порты. Если вам нужно задать MTU для гигабитных интерфейсов, то надо добавить слово jumbo.

System mtu jumbo и какое-то значение. Это два разных значения, две разные команды, две разные настройки. Очень часто ошибка, что люди думают: system mtu 1600 поставил или 1998, и оно ко всем интерфейсам применилось. Нет. Она применится только к 10/100. Дальше. System mtu routing указывает MTU для интерфейсов VLAN, то есть Switch Virtual Interface, и для интерфейсов, которым мы повесили no switchport, то есть интерфейсы, переведённые в маршрутизируемый режим. Про них мы поговорим на свитчинге. Тоже получается, что отдельная команда для них есть. И есть ещё system mtu alternative. Здесь она на слайде не показана, но она бывает. Для некоторых интерфейсов вы можете сказать, что дефолтное значение, заданное system mtu или system mtu jumbo, вас не устраивает. И для некоторых интерфейсов вы хотите сделать пометку, что он другой.

System mtu alternative указывает, какое MTU будет у таких вот других, не таких как все, интерфейсов. Но тоже одно на всю систему. Вы можете сказать, что этот интерфейс 10/100, этот интерфейс гигабитный или выше, а этот интерфейс — alternative, другой. И у вас только три возможности задать MTU на интерфейсах. Далее. Если вы хотите включить Jumbo Frame, то вам, скорее всего, как раз потребуется system mtu jumbo. Слово jumbo в команде и Jumbo Frame — это вещи, напрямую не связанные. Jumbo в команде — это для гигабитных и 10-гигабитных интерфейсов. System mtu jumbo не означает, что вы обязательно включаете Jumbo Frame, например, 9-килобайтные. Но если вы захотите включить Jumbo Frame, то вы, наверное, захотите сделать это на гигабитных интерфейсах. И команда будет system mtu jumbo 9000.

Если вы меняете MTU, то меняете его одинаково и однотипно на всех железках в пределах вашего широковещательного домена. Потому что иначе это будет проблемой. Какие-то узлы будут отправлять кадры большие, а другие принять их не смогут. Для работы IP поверх Ethernet нам потребуется ARP. И здесь ещё IARP нам поможет посмотреть, кто за каким портом нам известен. И за каким MAC. Плюс дополнительно таблицу коммутации на свитче можно посмотреть командой show mac address-table. Покажется, какие MAC мы знаем, в каком VLAN и за каким портом. Теперь, что касается PPP, который я вам обещал, что мы на него сделаем лабу. Я думаю, что мы сегодня как раз сделаем PPPoE, а завтра уже будем поднимать DMVPN. Если у нас есть прямо Serial Interface, то для того, чтобы включить на нём PPP, достаточно просто указать encapsulation ppp.

И оно само заработает. Если с двух сторон включили PPP здесь и включили PPP здесь, то оно нормально будет работать. Сразу поднимается. Как только мы отправляем и принимаем PPP-кадры, он заводится. Признаком того, что всё хорошо, что PPP завёлся, является то, что интерфейс у нас переходит в up. Физика переходит в up, если биты нормально передаются. Но биты на serial-линке передаются только одним способом. А вот line protocol в up показывает, что у нас согласовался протокол LCP. И здесь действительно LCP open. И дальше показывается, что у нас всё хорошо, что интерфейс в up. То, что NCP начал работать и согласовался или не согласовался, показано здесь: у нас IPCP stopped. Это значит, что IP мы попытались согласовать. Мы повесили, например, командой ip address что-нибудь.

Мы со своей стороны попытались согласовать IP, а с другой стороны IP-адрес не был повешен, и там IPCP ничего не ответил. Поэтому stopped означает, что мы со своей стороны попытались, а с той стороны ничего не получилось. В такой ситуации этой строчки быть не должно. Если бы с той стороны был IPCP тоже, он бы ответил и сказал: да, всё хорошо, давай дружить. А вот, например, такой служебный протокол CDPCP, CDP Control Protocol, он согласовался и сказал: да, всё нормально, такие кадры передавать можно. И у нас действительно CDP-кадры могут бегать в этом интерфейсе. Дальше. CRC-16 указывает на то, какая чек-сумма используется. Если у нас есть интерфейс, в этом интерфейсе мы отправляем кадры, в каждом кадре есть чек-сумма. CRC-16 указывает на то, что эта чек-сумма будет 2-байтовой, потому что в PPP можно переключаться между 2-байтовой и 4-байтовой чек-суммой. Здесь у нас получается 2-байтовая. И раз в 10 секунд мы посылаем keepalive, и если с той стороны никто нам на них не отвечает, то через некоторое время интерфейс упадёт, даже если на физике кажется, что он живой.

Если мы хотим использовать проверку подлинности, нам придётся задействовать протокол проверки подлинности — либо PAP, либо CHAP. В случае с PAP мы используем на интерфейсе команду ppp pap sent-username и login, и дальше password и пароль. Учитывая, что это password, здесь у нас хранится пароль в открытом виде, потому что мы его должны будем передавать в открытом виде. И если вдруг мы задействуем service password-encryption, то эта штука нам закодирует и превратит в нечитаемый набор символов. Но это будет обратимое шифрование. И по факту, когда сосед пришлёт нам сообщение «давай, показывай пароль», можно будет из закодированного пароля вытащить оригинальное исходное значение. Использовать здесь secret не получится, потому что secret хранит только хэш от пароля. А нам здесь нужен оригинал. И для того, чтобы включить проверку подлинности на том, кто хочет проверять эту самую подлинность, на R2 мы заводим учётку.

Username R1, password, дальше указываем пароль. В PAP можно здесь указать secret. И мы укажем, что у нас есть secret 123. И дальше ppp authentication pap. Мы требуем, чтобы когда мы поднимаем интерфейс serial 0/1/0, сосед должен предъявить свою учётную запись. И когда интерфейс включается, мы отправляем Configuration Request PAP. Сосед говорит: окей, я отправляю сообщение, что меня зовут R1, и у меня пароль Network Authentication 123. Если у нас здесь был username R1 password NE123, то мы сравниваем то, что пришло, с тем, что у нас хранится, и пропускаем. Если у нас здесь был secret, то мы берём хэш от пришедшего пароля, сравниваем с тем хэшем, который хранится в базе, и опять же пропускаем. Очень просто, очень примитивно. Если мы используем CHAP, то конфигурация немножко отличается.

Нам нужно будет на аутентифицируемом R1 тоже прописать запись в таблице локальных учётных записей с хостнеймом роутера-соседа, на котором мы аутентифицируемся, и паролем, который мы должны будем использовать. Либо альтернативный вариант: вместо записи в таблице учётных записей вы можете задать две команды — ppp chap hostname и ppp chap password. Обе команды, по сути, будут указывать на то, какой пароль вы будете отсылать. В случае, если вы указываете ppp chap hostname, то вы можете указать, какой логин вы отсылаете. Но если вы указываете не эти команды, а запись в таблице учётных записей, то тогда логином будет ваш hostname, а пароль будет браться из списка локальных учётных записей по хостнейму того, на ком вы аутентифицируетесь.

Challenge здесь автоматически выбирается. Challenge R2 пришлёт, и когда он присылает challenge, он раскрывает, что его зовут R2. Вот у нас схема. R2 сначала присылает challenge, он говорит: меня зовут R2, и challenge для тебя 12345. R1 говорит: окей, тебя зовут R2, и ты мне прислал challenge 12345. Я сейчас посмотрю, пробегусь по списку локальных учетных записей, найду учетку, соответствующую R2. У нее будет какой-то пароль. Я возьму этот пароль, возьму тот челлендж, который мне прислал R2, сложу одно с другим, возьму от этого хэш и отправлю в сторону спрашивающего, в сторону R2. Если мы прописываем в явном виде ppp chap hostname, ppp chap password, то тогда нам не надо в локальной базе держать учетку, мы просто говорим, что к нам пришел какой-то челлендж. Мы берем пароль, который здесь прописан, складываем его с челленджем,

прикладываем хостнейм, который у нас на интерфейсе прописан, и тогда отправляем. На экзамене этот механизм вас спрашивать не будут. Это CCI-шная тема, что можно прописать на интерфейсе в явном виде, какой логин и какой пароль отправлять. На экзамене надо будет знать вот эту штуку, что вы можете прописать юзернейм и пароль, пароль, причем, обязательно в открытом виде, именно со словом password, и юзернейм должен совпадать с хостнеймом соседа. Пароль при этом на железках должен быть одинаковый. Смотрите, на R1 мы прописываем R2 с паролем NE123, на R2 мы прописываем R1 с паролем NE123. Это то, что надо знать на экзамене. На мой взгляд, это немножко идиотизм, потому что, когда мы настраиваем всякие VPN и прочее в PPP, мы нигде не прописываем, что мы будем отправлять такой же пароль, как у соседа. Мы прописываем просто, что на этом интерфейсе мы используем такой-то логин, такой-то пароль. И это более логично. На мой взгляд, эту конфигурацию, если уж ее использовать — да, она пара,

логин, пароль. Но на экзамене надо знать именно эту штуку. Если мы будем использовать Multilink, то есть команда PPP Multilink. Мы ее на физическом интерфейсе задаем, плюс к ней задаем PPP Multilink Group и дальше номер. Так же, как на EtherChannel, мы прописываем Channel Group, чего-нибудь там, Mode, чего-нибудь там еще. Так же, как в случае с EtherChannel, у нас поднимается виртуальный интерфейс, который называется Multilink, и дальше с номером группы. Интерфейс Multilink 1. Все настройки уже задаются на нем. У нас с вами, к сожалению, не будет Multilink, но на экзамене от вас не потребуется поднимать новый Multilink интерфейс, и в крайнем случае вам просто дадут в конфиге посмотреть на железку, на которой этот Multilink настроен. Не потребуется понимание, как он работает, но просто, чтобы вы не пугались того, как Multilink выглядит,

я вам про это рассказываю. На физических интерфейсах, которые входят в группу, есть команда PPP Multilink и PPP Multilink Group. И дальше на Multilink интерфейсе, уже самом виртуальном интерфейсе, задаются все настройки IP и всего остального. С другой стороны абсолютно идентично. А теперь то, что касается нас, то, что мы с вами захотим сегодня сделать. Команд будет достаточно много, поэтому нужно будет постараться их не забыть. Это то, чем мы с вами сейчас будем заниматься. У нас есть несколько роутеров, и эти роутеры соединены в одну большую широковещательную сеть. Они все подключены к одному свитчу. К этому же свитчу подключен центральный сервер, центральный роутер, Core 1, ну и на самом деле Core 2 тоже. Меня сейчас будет интересовать Core 1. Настройка, которую нужно будет сделать. Вот это у нас Core 1, и вот это будет ваш роутер,

ваш роутер R1. C чего-то там, R1. Я со своей стороны на сервере сделаю следующие вещи. Во-первых, я его переименую, потому что мне не нравится, когда роутер называется просто Router, и вам тоже рекомендую переименовать. У вас на названиях вкладок написаны те имена, которые я вам рекомендую сделать. C чего-то там R1, C чего-то там R2, C чего-то там R3, C чего-то там R4. Сделайте хостнеймом такие же имена на ваших железках. Во-вторых, я пропишу на каждого из вас пароли, потому что если мы поднимаем PPPoE, там внутри будет работать PPP, и как следствие мне, наверное, захочется проверить у вас логины и пароли. И поэтому я укажу, что пароль на каждого из вас будет какой-нибудь конкретный. Давайте предлагаю с вами договориться, что пароли мы будем использовать cisco маленькими буквами. Вот такой будет пароль у нас всегда и везде.

Дальше. Я здесь рассказываю, что я буду делать. Из этого не следует, что вы это должны будете каким-то образом понимать, либо что вы это должны будете воспроизвести. Просто я рассказываю, как настраивается PPPoE-шный сервер. Я укажу, что у меня есть физический интерфейс GigabitEthernet 0/1. На нем я указываю, что никаких настроек специальных нету, нет IP-адреса. И я показываю, что на этом интерфейсе я буду слушать группу PPPoE-VPN. У меня запускается на этом интерфейсе PPPoE-шный сервер. Группа PPPoE-VPN будет указывать, что да, действительно, можно подключиться по PPPoE к этому интерфейсу. И настройки интерфейса виртуального, который будет порождаться для каждого конкретного случая, будут браться с Virtual Interface 1, с Virtual Template 1. И этот шаблонный интерфейс Virtual Template 1 скажет, что IP-шник на моем интерфейсе будет браться с Loopback нулевого. Вот он. Что соседний IP-шник будет браться из некоторого пула.

Вот он, IP local pool. И что на этом интерфейсе требуется провести проверку подлинности с помощью протокола CHAP. Давайте попробуем это с вами сделать. Я сейчас возьму и настрою центральный роутер таким образом, чтобы он на всех интерфейсах, которые смотрят на вас, требовал бы предъявить учетную запись и позволил бы подключиться к центральному роутеру по PPPoE. Вы со своей стороны должны будете сделать то, что справа в рамочке есть. Переименовываетесь на интерфейсе, который смотрит на центральный роутер. Если у вас, я правильно помню, это Ethernet 0.0.101. Мы указываем... А можно сделать прямо на Ethernet 0.0. Давайте на Ethernet 0.0, чтобы без виланов пока. Просто Ethernet 0.0.

Мы указываем, что интерфейс — IP-шник нам не нужен. Интерфейс надо просто включить no shutdown-ом. PPPoE enable и PPPoE client dial pool number 1. Мы указываем, что на этом интерфейсе будет работать дозвончик номер 1. И на этом дозвончике мы указываем, что IP-шник, который нам выдаст сервер, надо будет принять. Размер пакетов, которые будут передаваться, будут не больше, чем 1492 байта. Это IP-MTU. Это не просто MTU. Это IP-MTU. Пакеты IP, которые мы будем передавать, они будут не более, чем эти. С учётом того, что есть у нас заголовок PPP-шный, который будет 8 байт. И поэтому PPP-шный пакет плюс IP-шный пакет пассажирский плюс транспортный заголовок Ethernet как раз нам дадут нормальный размер кадра. Encapsulation PPP-шный пакет. Dialer Pool 1 и всё остальное. Я сделаю так, что у вас эта картинка будет видна на слайде, поэтому не переживайте,

если вдруг вы не запомнили, что здесь за команду надо будет вводить. Давайте я пока сам настрою сервер. Я сейчас буду настраивать центральный роутер. У меня он уже даже переименован. Какая удача. Что я делаю? Ethernet User Name. User Name. C01-R1 Password Cisco C02-R1 Password Cisco C03-R1 Password Cisco C04-R1 Password Cisco Это, к сожалению,

не автоматизируется никак. Надо будет действительно ручками всё сделать. 8 09 10 11 12 13-го, 14-го нету. 15-1 Дальше. BBA group PPPoE Я её просто назову PPPoE. Дальше. Virtual template 1. Шаблон номер 1. Создаём интерфейс loopback 0, IP-шник. Какой-нибудь нам бы адрес использовать. 172.16.0.1 255.255.255.0.

IP-адрес, естественно. Template 1. Interface range Ethernet 0/0-3 Ethernet 1/0-3 Ethernet 2/0-3 Ethernet 3/0-3. На всех интерфейсах no shutdown. Не помню, делал или нет. И указываю PPPoE enable group PPPoE. Interface IP unnumbered. Команда IP unnumbered берёт IP-шник с интерфейса. Она говорит, что не надо на этом интерфейсе держать отдельный адрес. Достаточно иметь такой же IP-шник, как на интерфейсе loopback 0. Очень удобно в некоторых случаях.

Peer default IP address pool PPPoE. Authentication CHAP. И последняя команда — IP local pool PPPoE. 172.16.0.101 — 172.16.0.120. То, что у вас показывает, что интерфейс перешёл в up, это всё нормально, так и должно быть. Виртуальный интерфейс, virtual access 2, да, он нормальный.

Возвращаемся к настройке маленьких роутеров. Сейчас мы с вами будем делать всё вместе. Я сейчас настроил центральный роутер. На всех интерфейсах, которые смотрят на вас, я завёл PPPoE сервер. Я прописал кучу учёток. Я прописал, что у меня есть группа PPPoE, которая берёт настройки виртуальных интерфейсов с шаблона номер 1. Я прописал, что мой IP-шник на этих шаблонных интерфейсах будет такой же, как на loopback 0 — 172.16.0.1. Ваши IP-шники будут браться из пула PPPoE pool. И я на этих интерфейсах требую аутентификацию CHAP, буковку P забыл. Теперь на маленьких роутерах мы с вами ответные действия будем делать. У меня роутер абсолютно не настроенный. Он показывает, что ничего не сделано. И мы с вами будем пытаться сейчас настроить всё это дело одновременно друг с другом. Диалог в начале настройки требует некоторого времени для того, чтобы от него можно было отказаться.

Сейчас у меня железка будет называться просто роутер. Я указываю, что зовут меня hostname C15-R1. Звук периодически пропадает по громкости. Знаете, с чем это может быть связано? Когда я одновременно печатаю и у меня перерисовывается экран, видеокартинка начинает зажимать больше полосы пропускания, и под звук остаётся меньше. Поэтому, если вдруг такое будет происходить, говорите мне, пожалуйста. Я буду стараться не говорить и не печатать одновременно. Это известный known bug, и я знаю, как с ним бороться. Поэтому, если вдруг такое будет, говорите про это. Нет, я не отворачиваюсь. У меня микрофон постоянно перед лицом. Hostname прописал.

Интерфейс. Сейчас я, понятное дело, тише говорю, когда я просто проговариваю команды, которые я выполняю, я просто их потише говорю. Интерфейс Ethernet 0.0. No shutdown. Интерфейсы все у нас, как вы помните, выключены. PPPoE enable. PPPoE client dial pool number 1. И клиента прописываем. PPPoE client dialer pool number 1. Что на этом интерфейсе будет работать виртуальный интерфейс номер 1. И даём настройки этого виртуального интерфейса. Interface dialer 1. IP address negotiated.

Сейчас я просто перепечатываю со слайда. No shutdown. IP MTU 1492. Encapsulation PPP. Dialer pool 1. PPP CHAP hostname — и здесь мне надо будет правильно указать свой hostname — C15-R1. PPP CHAP password маленькими буквами Cisco, как договаривались. PPP IPCP route default. Последняя команда. PPP IPCP Route Default Будет указывать, что если нам IPCP согласуют настройки IP То тогда мы на того, кто прислал нам все настройки по IPCP Ставим маршрут по умолчанию Я вижу, что у меня

после того, как я все команды ввёл что-то завелось Тут куча всякой диагностики пробежала И можно будет сейчас её разобрать Что именно получилось Во-первых, я вижу, что интерфейс у меня после того, как я указал, что нужно выполнять аутентификацию упал в даун Но через некоторое время поднялся снова И поднялся снова он как раз после того, как я прописал хостнейм и пароль Когда я сказал, что надо бы показывать логин и пароль PPP огорчился Когда я сказал, какие должны быть логин и пароль PPP снова обрадовался и интерфейс завёл Теперь я могу посмотреть, какие настройки согласовались PPP у нас зажёгся PPP получил, вероятно, IPшник И команда do show ip interface должна нам показать, какой IPшник назначился Я вижу действительно, интерфейс в API Интерфейс получил IP адрес 172.16.102 И метод у него IPCP

Мы со своей стороны настроили всё Мы убедились, что интерфейс поднялся Можно взять и попингать центральный роутер Так PPP 172.16.0.1 Он пингается Я думаю даже, что мы можем друг друга попингать Нет, не можем Видим, маршрута нет Что у нас таблица маршрутизации-то там? Show ip route Да, у нас дефолт не поставился Фишка в том, что центральный роутер не настроен на отдачу этого самого дефолта И если мы пропишем маршруты например, дефолтный маршрут на центральный роутер то он уже позволит работать с IP-пакетами между нашими роутерами Между, допустим, 101, 102, 103 и так далее

Естественно, надо с обеих сторон будет прописать Если вы хотите на меня посылать пакеты у вас должен быть дефолт И у меня должен быть дефолт для того, чтобы такие пакеты отдать Так, у нас на выходе может быть 1508 Или я пока туплю Нет, у нас на выходе 1508 не должно быть У нас должно быть на выходе 1500 И не больше Если мы заворачиваем какие-то пакеты в дополнительные заголовки то мы должны будем убедиться, что то, что вкладывается внутри дополнительных заголовков не превышает цифру в 1492 байта, например Если мы говорим, что у нас вложение может быть 1500 байт плюс ещё в заголовке 8 байт надо будет убедиться тогда, что вся транспортная сеть с такими пакетовыми переростками сможет нормально работать Да, из ГРЭ такая же ситуация Только у PPPOE дополнительный заголовок занимает 8 байт А у ГРЭ он занимает непредсказуемое количество байтов Может 4 байта занимать, может 8, может 12 И плюс ещё дополнительно транспортный IP заголовок

тоже занимает место И там 20 байт Но такая классическая ситуация ГРЭ 8 байт плюс заголовок IP 20 байт Поэтому служебные заголовки, которые мы навешиваем на каждый ГРЭшный пассажирский пакет будут 28 байт занимать И поэтому МТУ на ГРЭшных туннелях должно быть не больше, чем 1472 Чтобы 28 байт ещё дополнительно всякого мусора на каждый пакет можно было повесить Если вдруг вы будете использовать какое-нибудь шифрование а с ГРЭ норма использовать дополнительное шифрование то тогда пакет, который был зашифрован, может немножко распухнуть в объёме И тогда имеет смысл сказать что у нас даже не 1472 байта максимальный размер пакета, уходящего в ГРЭшный туннель а там 1450 Если вы помните CCNA, рекомендация Циски вообще 1400 вешать Потому что все эти дополнительные заголовки шифрование, какая-нибудь ещё лабуда там будет И всё это непредсказуемого размера может получиться в итоге

Поэтому 1400 — это с запасом И да, если вы не можете отправить пакет в этот туннель потому что он превышает по размеру то вы такой пакет либо порежете на части с фрагментацией либо пристрелите, если там был флаг DF И тогда механизм Path MTU Discovery на том отправителе который такой пакет не смог отправить сделает так, чтобы следующие пакеты отправлялись уже поменьше Поэтому да, в ГРЭ такая же ситуация И в PPPOE такая же ситуация Впрочем, если вы как клиент провайдера подключаетесь по PPPOE к провайдеру то тогда вам МТУ задавать не надо 1500 Провайдер со своей стороны понимает, что когда вы подключаетесь к нему вы хотите отправлять 1500-байтовые пакеты И поэтому он со своей стороны на своих свичах, на своих роутерах на своём BRAS — Broadband Remote Access Server который терминирует PPPOE он уже со своей стороны подкрутит МТУ

Чтобы ваши 1500-байтовые пакеты плюс 8 байт заголовка нормально по его провайдерской сети проходили Но мы с вами сейчас не работаем с провайдером Мы строим PPPOE поверх нашей собственной сети И чтобы нигде не подкручивать транспортный МТУ мы сказали: давайте подкрутим PPPOE-шный МТУ Это будет проще всего Так, что ещё хотел сказать Давайте посмотрим про диагностику PPPOE Чего здесь у нас будет Если вы хотите посмотреть на то, как у вас работает интерфейс то самое простое, что можно придумать, это show interface Show interface у вас есть DLR1 И он показывает всякое разное про именно тот интерфейс, который дозванивается до сервера Показывается, что интерфейс в API Канальный уровень тоже в API Этот интерфейс получил какой-то IPшник И свойства этого интерфейса

показываются, что МТУ у него какой-то там Вообще он, конечно, должен быть 1392, по идее Bandwidth 56 килобит в секунду Bandwidth нарисованный у PPPOE PPPOE не может оценить интерфейс, который он нарисовал Какая у него будет пропускная полоса Поэтому он ставит минимально возможную полосу, которая ему приходит в голову Он говорит, что полоса будет там 56 килобит Задержка будет 20 миллисекунд на этом интерфейсе Опять же, он не может её оценить, поэтому он ставит её такую большую Это причём задержка сериализации, которая якобы будет Надёжность максимальная, загрузка минимальная На отправку, на приём И LCP Closed Это нормально То, что по факту у нас получается: интерфейс, на котором работает PPP, LCP Open, IPCP это виртуальный интерфейс, который клонируется с настроек DLR1 И здесь LCP по факту работает

IP по факту работает И свойства интерфейса все переезжают Не настройки, а свойства интерфейса все переезжают Это всё в выводе Show Interface DLR1 Здесь просто вывод сокращён чтобы не печатать всю колбасу про всякие каунтеры, счётчики, ошибки и так далее Этот блок автоматически добавляется к выводу Show Interface DLR1 Так Да, MTU тоже 1500 Я думаю, что эмулятор, который у нас используется он просто не совсем корректно отрабатывает это значение MTU Да, на сервере аналогичная ситуация Только интерфейс надо сразу заказывать с Virtual Access а не DLR Там DLR нету И показывается: интерфейс в API канальный уровень в API

IPшник используется с лупбека нулевого вот такой IPшник MTU подкрутили Bandwidth и delay Поскольку это виртуальный интерфейс, который виртуальный тип и сервер то он заимствует bandwidth со своего интерфейса, на котором он запущен И показывается, что LCP у нас согласовался и IPCP у нас по факту тоже работает Фишка в том, что когда вы запускаете сервер вы в явном виде говорите, на каком интерфейсе этот сервер работает А когда вы клиента запускаете вы не говорите, на каком интерфейсе работает дайлер Вы привязываете интерфейс к дайлеру, но не наоборот Поэтому дайлер ничего не знает про производительность А вот Virtual Access знает Так ДТР Честно говоря, не знаю Не приходит в голову ничего А где вы это увидели? Да, далее А далее там уже фрейм рилей идёт Давайте фрейм рилей на завтра оставим Это уже поздно И сегодня мы с вами попробовали посмотреть на то, как настраиваются циски Сделали первую лабу

Пусть и такую простенькую, пусть и не самую интересную Но тем не менее лабу И завтра поговорим про все остальные канальные среды, которые в цисках есть На сегодня всё Спасибо за внимание Пока-пока