Комментарии 43
Хороший конспект, спасибо!
У меня не хватило пороху переписать из блокнота.
Единственное, я бы перед описанием настройки упомянул аппаратную конфигурацию — что, как, с чего, куда консольный кабель втыкать.
У меня не хватило пороху переписать из блокнота.
Единственное, я бы перед описанием настройки упомянул аппаратную конфигурацию — что, как, с чего, куда консольный кабель втыкать.
Не забывайте про отложеную перегрузку при конфиге устройства, которое находится далеко от вас. Бывает, что сильно помогает :)
…
router#reload in 30
(перегрузка через 30 минут)
…
router#reload in 30
(перегрузка через 30 минут)
Паршивое решение. Надо делать configure replace — он не перезагружает железку целиком, а сравнивает текущую конфигурацию с указанным конфигурационным файлом, находит несоответствия и вводит команды для устранения несоответствий. В том числе по таймеру.
www.cisco.com/en/US/docs/ios/fundamentals/configuration/guide/cf_config-rollback.html#wp1146581
Все-таки курс CCNA сильно оторван от жизни. Например, ну кто в реальной жизни делает «copy runn start»? Покажите мне этого человека, я хочу убедиться, что он действительно существует.
www.cisco.com/en/US/docs/ios/fundamentals/configuration/guide/cf_config-rollback.html#wp1146581
Все-таки курс CCNA сильно оторван от жизни. Например, ну кто в реальной жизни делает «copy runn start»? Покажите мне этого человека, я хочу убедиться, что он действительно существует.
Пусть паршивое, но универсальное и работает везде, в отличие от configure replace.
А где (из IOS либо IOS XE устройств) не работает config replace?
«Reload in» лучше не использовать никогда, кроме как в качестве дополнительной страховки (в случае острой паранойи) — к примеру, replace через 2 минуты и reload in через 5, если первый что-то сломает. Хотя ни разу с таким не сталкивался.
«Reload in» лучше не использовать никогда, кроме как в качестве дополнительной страховки (в случае острой паранойи) — к примеру, replace через 2 минуты и reload in через 5, если первый что-то сломает. Хотя ни разу с таким не сталкивался.
На старом железе и со старыми иосами не работает. Также не нашел этой фичи в ASA/PIX. Такого добра у нас еще много, оно работает и менять живое железо нету смысла. Например с2621, с2509, С2950…
Сочувствую.
Но это не отменяет того факта, что на железе, которое не «древнее как говно мамонта и объявлено EOL чуть ли не в прошлом веке», надо пользоваться современными средствами. И желательно сразу к ним привыкать.
Но это не отменяет того факта, что на железе, которое не «древнее как говно мамонта и объявлено EOL чуть ли не в прошлом веке», надо пользоваться современными средствами. И желательно сразу к ним привыкать.
Зачем же сразу привыкать. Наверное для того, чтобы, столкнувшись потом с железкой, где эта фича не работает (в жизни все бывает, да), вспоминать, как же называлась та команда, которая позволяла перегруз по заданому времени? :)
Я за универсальные решения. Хотя «config replace» хороша, спору нет.
Я за универсальные решения. Хотя «config replace» хороша, спору нет.
Ну я вот например очень привык к командам ios.sh. Очень удобно сделать «show XXX | grep YYY | grep -v ZZZ | wc -l» или что-то вроде того. Но работает оно только на софтовых роутерных платформах с иосом 15.1.4М и выше. Тем не менее, это не мешает получать массу удовольствия от использования этой фичи там, где она поддерживается.
Хм… а чем copy runn start не угодил?? я так делаю, например. поделись мудростью почему не стоит и как стоит делать?
или ты про wr? )
или ты про wr? )
Я делаю.
Стоит ещё добавить секцию про t1/e1 и секцию про frame relay. К сожалению, очень часто попадаются на практике tdm-потоки, да и fr ещё многие любят.
Господа, это заметки с курса ICND1. Я сразу предупредил про «неполноту» этих заметок. Есть “configure replace” -можно спорить про полезность команды (не всегда и не везде); есть команда “archive” (полезна). Да и вообще, Cisco свой банальный менеджмент маскирует, много чего примитивного есть в TSHOOT, IINS. В общем, разбросано. Да, многие из вас правы – доки с cisco.com.
Цель поста немного другая – расшевелить интересующихся cisco, развлечь спецов. Может кто добавит, чего-нибудь и будет нормальный русский гайд.
Цель поста немного другая – расшевелить интересующихся cisco, развлечь спецов. Может кто добавит, чего-нибудь и будет нормальный русский гайд.
очень хорошо структурировано.
>Поддержка VLSM/CIDR…
Не совсем верно указано.
Classfull — RIPv1 и IGRP — С этим согласен.
Но! Classless, (он же CIDR) это только RIPv2.
А вот BGP, OSPF, EIGRP и IS-IS это уже не просто CIDR, а ещё и VLSM.
Принципиальная разница в том, что RIPv2 не умеет VLSM, поэтому некорректно ставить его в один ряд с OSPF и прочими.
Не совсем верно указано.
Classfull — RIPv1 и IGRP — С этим согласен.
Но! Classless, (он же CIDR) это только RIPv2.
А вот BGP, OSPF, EIGRP и IS-IS это уже не просто CIDR, а ещё и VLSM.
Принципиальная разница в том, что RIPv2 не умеет VLSM, поэтому некорректно ставить его в один ряд с OSPF и прочими.
RIPv2 не умеет VLSM
www.ciscopress.com/articles/article.asp?p=102174&seqNum=4
RIPv2 improves upon RIPv1 with the ability to use VLSM, with support for route authentication, and with multicasting of route updates. RIPv2 supports CIDR
А расскажите-ка своими словами про разницу между CIDR и VLSM :)
Что вы понимаете под «не умеет VLSM»? RIPv2 маску в апдейтах передает, как и прочие classless протоколы. Хоть subnets (no auto), хоть суммарные (ip summary-address rip…). Т.е. умеет.
CIDR — предполагает что маска сети может отличаться от классовой и предлагает форму записи таких масок в виде длины префикса. Да, RIPv2 передаёт в пакете маску подсети и она может отличаться от стандартных масок классовых сетей.
VLSM — предполагает дробление одной классовой сети на множество подсетей более узких (речь идёт именно про подсети — SUBNET MASK), но с переменной длинной префикса (собственно в этом и заключается VARIBLE LENGTH). Да, RIPv2 может передать информацию о нескольких подсетях входящих в одну сеть с маской более узкой, чем классовая и даже c разной длиной префикса.
Но! В RIP (независимо от версии) вы не можете указать в команде network маску, а выполнение комнады «network 10.10.10.0», например, в конфиге превратится в 10.0.0.0 фактически с маской /8. RIP умеет охватывать только всю классовую сеть целиком. Конечно можно использовать passive-interface и distribute list'ы, но это уже костыли.
В случае если у вас на роутере все интерфейсы из диапазона 10.0.0.0/8, и вам нужно через один из них поднять RIP с соседом, но не сообщать ему о своих остальных сетях, а только принимать маршруты от него, то эта задача решается только с помощью distribute-list'ов. В OSPF, EIGRP или BGP этот вопрос закрывается командой network c узкой маской (как правило /30 на транзитных сетях).
Я наверное погорячился на счёт того что RIPv2 совсем не умеет VLSM. С точки зрения передачи информации о сетях — конечно умеет, но вот с точки зрения настроек самого протокола маршрутизации — нет.
VLSM — предполагает дробление одной классовой сети на множество подсетей более узких (речь идёт именно про подсети — SUBNET MASK), но с переменной длинной префикса (собственно в этом и заключается VARIBLE LENGTH). Да, RIPv2 может передать информацию о нескольких подсетях входящих в одну сеть с маской более узкой, чем классовая и даже c разной длиной префикса.
Но! В RIP (независимо от версии) вы не можете указать в команде network маску, а выполнение комнады «network 10.10.10.0», например, в конфиге превратится в 10.0.0.0 фактически с маской /8. RIP умеет охватывать только всю классовую сеть целиком. Конечно можно использовать passive-interface и distribute list'ы, но это уже костыли.
В случае если у вас на роутере все интерфейсы из диапазона 10.0.0.0/8, и вам нужно через один из них поднять RIP с соседом, но не сообщать ему о своих остальных сетях, а только принимать маршруты от него, то эта задача решается только с помощью distribute-list'ов. В OSPF, EIGRP или BGP этот вопрос закрывается командой network c узкой маской (как правило /30 на транзитных сетях).
Я наверное погорячился на счёт того что RIPv2 совсем не умеет VLSM. С точки зрения передачи информации о сетях — конечно умеет, но вот с точки зрения настроек самого протокола маршрутизации — нет.
CIDR — предполагает что маска сети может отличаться от классовой и предлагает форму записи таких масок в виде длины префикса.
CIDR может существовать без VLSM?
В RIP (независимо от версии) вы не можете указать в команде network маску, а выполнение комнады «network 10.10.10.0», например, в конфиге превратится в 10.0.0.0 фактически с маской /8.
Я паршиво помню RIP, но из того, что помню: требуется одна команда, чтобы анонс сетей начал производиться в точности как на OSPF/EIGRP. То ли ":ip classless", то ли просто «version 2». В итоге можно привычно указать адрес и инверсную маску.
Вы, кстати, в курсе, что и в RIP, и в EIGRP, и в OSPF инверсная маска после «network» не имеет ни малейшего отношения к маске подсети? ;)
CIDR может существовать без VLSM?
Да, если это суммаризация сетей, у нас может быть сеть класса B (172.0.0.0), а маска /8. Т.е. маска отличается от классовой, но речь не идёт про VLSM, так как это суперсеть, а не подсеть.
В прочем это уже скорее тавтология ))))
В итоге можно привычно указать адрес и инверсную маску.
Увы, нельзя. Ip classless не помогает.
Вы, кстати, в курсе, что и в RIP, и в EIGRP, и в OSPF инверсная маска после «network» не имеет ни малейшего отношения к маске подсети? ;)
1) Я по прежнему настаиваю на том, что в RIP указать маску нельзя, ни прямую ни инверсную.
2) Ну в том же OSPF она только обратная и используется и указывает именно на МАСКУ. Не понял, что вы имели ввиду?
Да, если это суммаризация сетей
Правильный ответ — нет.
CIDR — концепция отказа от классовых масок.
VLSM — возможность передавать префиксы с маской.
Я по прежнему настаиваю на том, что в RIP указать маску нельзя
Да, я был не прав. Но: это лишь особенность работы команды network. Во всех анонсах маска передается. Соответственно — VLSM полностью поддерживается.
в том же OSPF она только обратная и используется и указывает именно на МАСКУ
То есть если есть интерфейс 10.0.0.1/24, и в процессе OSPF сказать «network 10.0.0.1 0.0.0.0 area 0», то OSPF на данном интерфейсе не заработает?
Что-то я вас совсем не понимаю…
Заработает, так как в команде network указана сеть 10.0.0.1 и маска 0.0.0.0, которая объявляет все биты этой сети значимыми, а на интерфейсе у нас ровно то же занчение — 10.0.0.1. Т.е. OSPF вот только на этом интерфейсе и заработает (ну при условии, что нет других команд network).
Но ведь 0.0.0.0 — это и есть МАСКА, которая указывает нам какие биты считать значимыми, а какие нет.
А ну да… к маске ПОДСЕТИ это точно не имеет никакого отношения! Это другая МАСКА. Конечно, согласен. Не учёл слово «подсети», получилось, что «инверсная маска после «network» не имеет ни малейшего отношения к маске», что и вызвало непонимание.
Заработает, так как в команде network указана сеть 10.0.0.1 и маска 0.0.0.0, которая объявляет все биты этой сети значимыми, а на интерфейсе у нас ровно то же занчение — 10.0.0.1. Т.е. OSPF вот только на этом интерфейсе и заработает (ну при условии, что нет других команд network).
Но ведь 0.0.0.0 — это и есть МАСКА, которая указывает нам какие биты считать значимыми, а какие нет.
А ну да… к маске ПОДСЕТИ это точно не имеет никакого отношения! Это другая МАСКА. Конечно, согласен. Не учёл слово «подсети», получилось, что «инверсная маска после «network» не имеет ни малейшего отношения к маске», что и вызвало непонимание.
А ну да… к маске ПОДСЕТИ это точно не имеет никакого отношения!
Поднимаем переписку:
«инверсная маска после «network» не имеет ни малейшего отношения к маске подсети»
«в том же OSPF она [маска] только обратная и используется и указывает именно на МАСКУ»
Так на какую маску указывает инверсная маска? :)
Эх, жалко, что softline_education всё испортил подробным объяснением :)
промахнулся с ответом…
что-то тупит у меня хабр, не мог я три раза промахнуться, пытаясь ответить JDima!
)))))))
)))))))
VLSM и CIDR обуславливают возможность отказаться от класса сети ииспользовать для определения сетевой\хостовой части маску. Маска включается для передачи информации о сетях. RIPv2 это все умеет.
Другой момент, о котором вы указали, состоит в том, что реализация RIPv2 в IOS не позволяет выбрать конкретные интерфейсы, участвующие в работе протокола. OSPF, EIGRP позволяет вам четко выбирать интерфейсы, указывая маску. Синтаксис OSPF/EIGRP: network 10.1.1.0 0.0.0.255 …
К примеру:
fa0/0 10.1.1.1/24
fa0/1 10.2.2.1/24
Ospf или EIGRP (с EIGRP используем no auto-sum):
Network 10.0.0.0 0.255.255.255
Отдаст две сетки 10.1.1.0 и 10.2.2.0/24
Network 10.1.1.0 0.0.0.255
Отдаст только 10.1.1.0/24
RIP:
Network 10.0.0.0 — иначе не позволяет. В итоге и fa0/0 и fa0/1 участвуют в рипе.
А отдаваемые сети будут зависеть от наличия суммирования (auto-summ или ip summary-addr). Если включено суммирование, то уходит 10/8, если нет, то обе подсети.
С RIP вы указываете классовый адрес и, как следствие, все интерфейсы в этом классе начинают работать в RIP. И, да, для исключения определенного интерфейса нужны distribute-lists, passive-interface и т.д. Надо посмотреть на RIP у других вендоров, как все это реализовано у них. Cisco видимо его особо значимым протоколом не считает (что верно) и не заморачиваясь синтаксис тупо перенесла с первого рипа.
А с BGP совсем другая история… Если в остальных протоколах вы выбираете интерфейсы и сеть интерфейса анонсится, то в BGP вы сами анонсите сети. У команды network в BGP совсем другое значение.
Другой момент, о котором вы указали, состоит в том, что реализация RIPv2 в IOS не позволяет выбрать конкретные интерфейсы, участвующие в работе протокола. OSPF, EIGRP позволяет вам четко выбирать интерфейсы, указывая маску. Синтаксис OSPF/EIGRP: network 10.1.1.0 0.0.0.255 …
К примеру:
fa0/0 10.1.1.1/24
fa0/1 10.2.2.1/24
Ospf или EIGRP (с EIGRP используем no auto-sum):
Network 10.0.0.0 0.255.255.255
Отдаст две сетки 10.1.1.0 и 10.2.2.0/24
Network 10.1.1.0 0.0.0.255
Отдаст только 10.1.1.0/24
RIP:
Network 10.0.0.0 — иначе не позволяет. В итоге и fa0/0 и fa0/1 участвуют в рипе.
А отдаваемые сети будут зависеть от наличия суммирования (auto-summ или ip summary-addr). Если включено суммирование, то уходит 10/8, если нет, то обе подсети.
С RIP вы указываете классовый адрес и, как следствие, все интерфейсы в этом классе начинают работать в RIP. И, да, для исключения определенного интерфейса нужны distribute-lists, passive-interface и т.д. Надо посмотреть на RIP у других вендоров, как все это реализовано у них. Cisco видимо его особо значимым протоколом не считает (что верно) и не заморачиваясь синтаксис тупо перенесла с первого рипа.
А с BGP совсем другая история… Если в остальных протоколах вы выбираете интерфейсы и сеть интерфейса анонсится, то в BGP вы сами анонсите сети. У команды network в BGP совсем другое значение.
Это всё понятно и известно.
Но в рамках поста про CCNA мы всё же говорим именно о cisco-вской реализации этих протоколов.
А в ней к сожалению RIPv2 не позволяет указывать маску в команде network и приходится лепить костыли.
Повторюсь, я не очень удачно назвал это отсутствием поддержки VLSM, но некоторое ограничение в работе тем не менее присутствует.
Но в рамках поста про CCNA мы всё же говорим именно о cisco-вской реализации этих протоколов.
А в ней к сожалению RIPv2 не позволяет указывать маску в команде network и приходится лепить костыли.
Повторюсь, я не очень удачно назвал это отсутствием поддержки VLSM, но некоторое ограничение в работе тем не менее присутствует.
В догонку ответу для g0ff и JDima:
Это, кстати, распространенный миф, что команда network чего-то там анонсирует (исключение, BGP). Ничего подобного – это просто выбор интерфейсов: интерфейс отправляет\получает апдейты, сетка интерфейса передается в апдейтах. Как анонсировать сеть интерфейса, IOS решит самостоятельно, в зависимости от наличия или отсутствия суммирования. И в IPv6 от подобной практики отказались, команды network нет. Вместо этого:
Int fa0/1
Ipv6 rip X enable
Ipv6 ospf X area Y
Для OSPF это можно делать и для IPv4:
Int fa0/1
Ip ospf X area Y
И в OSPF показательна show ip proto. Увидите там явно выбранные интерфейсы. Они как-то по другому отображаются.
Это, кстати, распространенный миф, что команда network чего-то там анонсирует (исключение, BGP). Ничего подобного – это просто выбор интерфейсов: интерфейс отправляет\получает апдейты, сетка интерфейса передается в апдейтах. Как анонсировать сеть интерфейса, IOS решит самостоятельно, в зависимости от наличия или отсутствия суммирования. И в IPv6 от подобной практики отказались, команды network нет. Вместо этого:
Int fa0/1
Ipv6 rip X enable
Ipv6 ospf X area Y
Для OSPF это можно делать и для IPv4:
Int fa0/1
Ip ospf X area Y
И в OSPF показательна show ip proto. Увидите там явно выбранные интерфейсы. Они как-то по другому отображаются.
Так как развивается дискуссия, и ушли далеко за ICND1, хочется подключить коммунити для составления нормального ИТ-словаря, хотя бы для сетей. Есть Олиферы, есть переводные книги, но нужен нормальный общеупотребимый сленг. Термины, используемые в этих книгах никто из нас не выговаривает. Мы используем англицизмы. У Cisco был прецедент перевода, как учебников, так и экзаменов. Провалился. Давайте определимся с языком, а то каждый на своем «английском» :)
Вы предлагаете стартовать проект сетевого глоссария прямо тут в комментах, или просто порассуждать в рамках данной дискуссии?
Как я уже сказал маска она и в Африке маска. А вы можете как-то разделить термины для маски указывающей размерность сети на интерфейсе и маски указываемой в настройках динамических протоколов маршрутизации?
P.S. А заодно ещё и той маски, которая используется в ACL, она ведь тоже не является МАСКОЙ ПОДСЕТИ через который проходит фильтруемый трафик?
;)
Как я уже сказал маска она и в Африке маска. А вы можете как-то разделить термины для маски указывающей размерность сети на интерфейсе и маски указываемой в настройках динамических протоколов маршрутизации?
P.S. А заодно ещё и той маски, которая используется в ACL, она ведь тоже не является МАСКОЙ ПОДСЕТИ через который проходит фильтруемый трафик?
;)
Такими темпами лучше уж совсем на английский перейти. Я согласен с тем, что терминологию лучше не переводить совсем («домен широковещательный рассылки» и «расщеплённый горизонт» я запомню на всю свою оставшуюся жизнь), но тогда на русском остаются в основном предлоги.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Краткие заметки по Cisco CCNA (часть ICND1)