Привет, незнакомец!

Похоже, вы здесь новенький. Чтобы принять участие, нажмите одну из кнопок ниже!

ospf network vs interface subcommand

a_sa_s
отредактировано апреля 2016 Раздел: OSPF
Вроде Cisco в руководствах более предпочитает
R3 has migrated its configuration away from the
older network commands, instead using the ip ospf area interface subcommand.
ospf area interface subcommand , чем router network. Почему? Ведь на первый взгляд видеть ospf сетки в одном месте удобнее?
Тэги темы:

Комментарии

  • С network проще накосячить и включить туда не те интерфейсы (точнее, они сами включатся). С поинтерфейсным вариантом можно посмотреть по sh ip os int br. Я думаю, network никуда не денется, так что дело вкуса.
  • Вообще-то по так называемому "best practice", после создания router ospf процесса, сразу же вписать router-id и passive-interface default, а потом включать на тех интерфейсах, где это необходимо. С EIGRP наоборот все настройки перенесли в router eigrp процесс, включая настройки интерфейсов.
  • EvgeniyHeine написал:

    С поинтерфейсным вариантом можно посмотреть по sh ip os int br.

    Jay-T написал:

    С EIGRP наоборот все настройки перенесли в router eigrp процесс, включая настройки интерфейсов.

    Вот зашел посмотреть сохраненные конфиги где нибудь на ftp и сразу в одной секции все перед глазами, все ospf сетки. Удобно же?
  • отредактировано марта 2016
    Jay-T написал:

    С EIGRP наоборот все настройки перенесли в router eigrp процесс, включая настройки интерфейсов.

    Да вот интересно почему, в router ospfv3 , для AF режима, не сделали тоже самое? :) для него настройки под интерфейсом...

    У меня сохраняется устойчивое впечатление - что задача циски, затруднить изучение их командной строки, в конце концов, командная строка циски, это по большей части древовидная менюшка...
  • Packo написал:

    Jay-T написал:

    С EIGRP наоборот все настройки перенесли в router eigrp процесс, включая настройки интерфейсов.

    Да вот интересно почему, в router ospfv3 , для AF режима, не сделали тоже самое? :) для него настройки под интерфейсом...

    У меня сохраняется устойчивое впечатление - что задача циски, затруднить изучение их командной строки, в конце концов, командная строка циски, это по большей части древовидная менюшка...
    Разумеется настройка под интерфейсом является более гранулированной. ISIS только так и настраивается.

    Нет никакой теории заговора. EIGRP и OSPF разные люди пилят. Я вам больше скажу, одну и туже фишку на ASR9k и CRS зачастую пишут разные команды, из разных стран.
  • отредактировано марта 2016
    Chelioz написал:


    Нет никакой теории заговора. EIGRP и OSPF разные люди пилят. Я вам больше скажу, одну и туже фишку на ASR9k и CRS зачастую пишут разные команды, из разных стран.

    Я думаю, что чтобы вызов процедур из одной команды командной строки в другую переместить не нужна целая бригада программистов. К тому же, интерфейсом в целом неплохо бы если бы занималась отдельная группа (уверен что она там существует - и это её косяк), иначе получается кашка...
  • Packo написал:

    Chelioz написал:


    Нет никакой теории заговора. EIGRP и OSPF разные люди пилят. Я вам больше скажу, одну и туже фишку на ASR9k и CRS зачастую пишут разные команды, из разных стран.

    Я думаю, что чтобы вызов процедур из одной команды командной строки в другую переместить не нужна целая бригада программистов. К тому же, интерфейсом в целом неплохо бы если бы занималась отдельная группа (уверен что она там существует - и это её косяк), иначе получается кашка...
    Софт не на коленке пишут. Чтобы что-то поменять - нужен запрос, запрос должны согласовать и обосновать его ценность. Потом нужно выделить программиста. Судя по тематике, приоритет будет самый низкий. Спустя месяц у него дойдут руки, а ещё надо выбрать релиз, в который это включить. Потом будет тестирование. Ещё придётся обновлять документацию на CCO. Сколько это в деньгах для циски, лучше даже не знать.
  • отредактировано марта 2016
    Chelioz написал:

    Сколько это в деньгах для циски, лучше даже не знать.

    Ну так если сразу организовать группу, которая занимается разработкой интерфейса и будет соединять внутренние процедуры отвечающие за функционал, написанные другими программистами, с единым интерфейсом командной строки, такой проблемы не будет существовать. Мне кажется у циски процесс производства ПО организован как надо (иначе была бы каша), и там такая группа присутствует, просто накосячили сразу (может ответственный инженер был в отпуске, а не замене был безответственный :) ), или специально сделали (EIGRP все таки же их проприетарный продукт)...

    Но, это все вопрос о том, сколько канадцев нужно чтобы вкрутить лампочку...

    А вообще идея спорная - повышение уровня вложенности = увеличение сложности, а не наоборот, как пишут "мы собрали всю конфигурацию EIGRP в кучу, чтобы облегчить настройку и интерпретацию конфига"
  • Потому что правило network не объявляет сеть, а говорит на каких интерфейсах запустить протокол OSPF. Всегда рекомендуется прописывать правило network c Wildcard 0.0.0.0, это точечно запускает OSPF на конкретном интерфейсе, что тоже самое, что запустить OSPF на интерфейсе. Добавили вы когда-то: network 192.168.0.0 0.0.255.255 area 0 для удобства для сетей 192.168.10.0/24 и 192.168.20.0/24 а потом у вас появилась дополнительная подсеть на этом маршрутизаторе 192.168.100.0/24, и OSPF запустится на этом интерфейсе сам, т.к. этот интерфейс покрывается правилом network. Более точечная политика всегда предпочтительнее и безопаснее, позволяет избежать потенциальных проблем ). Для OSPFv3 (для IPv6) остался только вариант запуска протокола на интерфейсе, что очень правильно и логично!
  • cann написал:

    Добавили вы когда-то: network 192.168.0.0 0.0.255.255 area 0 для удобства для сетей 192.168.10.0/24 и 192.168.20.0/24 а потом у вас появилась дополнительная подсеть на этом маршрутизаторе 192.168.100.0/24, и OSPF запустится на этом интерфейсе сам, т.к. этот интерфейс покрывается правилом network. Более точечная политика всегда предпочтительнее и безопаснее, позволяет избежать потенциальных проблем ). Для OSPFv3 (для IPv6) остался только вариант запуска протокола на интерфейсе, что очень правильно и логично!

    Можно точечно прописать 192.168.10.0/24 и 192.168.20.0/24 ?
  • Я думаю, за парсинг команд отвечает отдельный модуль, который никоим образом не связан с модулями OSPF и пр., и изменить формат команд довольно просто технически. Тянут, скорее всего, ради обратной совместимости, чтобы старый инженер, который всю жизнь писал network, tacacs server, wr и пр. не испытывал батхерта от внезапного изменения набора команд. Я вот сейчас смотрю курсы, там IOS XE + IOS XR. Так вот, в XR у инструктора процент ввода ошибочных команд просто ужасен из-за того, что там все перелопатили, сделали иерархическим и лишили ipv4 статуса протокола по-умолчанию. Да, еще ASA страдала таким внезапным измененением команд между версиями софта.
  • отредактировано марта 2016
    a_s написал:

    cann написал:

    Добавили вы когда-то: network 192.168.0.0 0.0.255.255 area 0 для удобства для сетей 192.168.10.0/24 и 192.168.20.0/24 а потом у вас появилась дополнительная подсеть на этом маршрутизаторе 192.168.100.0/24, и OSPF запустится на этом интерфейсе сам, т.к. этот интерфейс покрывается правилом network. Более точечная политика всегда предпочтительнее и безопаснее, позволяет избежать потенциальных проблем ). Для OSPFv3 (для IPv6) остался только вариант запуска протокола на интерфейсе, что очень правильно и логично!

    Можно точечно прописать 192.168.10.0/24 и 192.168.20.0/24 ?
    Точечно прописывается адрес интерфейса, например: 192.168.10.1 0.0.0.0 a 0; 192.168.20.1 0.0.0.0 a 0. Всё, вы точно уверены, что без вашего вмешательства OSPF сам на других интерфейсах не запустится. OSPF смотрит какие интерфейсы покрываются правилом network (в нашем случае только 2 - 10.1 и 20.1) идет на интерфейс, смотрит маску и её уже анонсирует, а не то, что прописано через network. Или запускайте OSPF непосредственно с интерфейса.
  • Packo написал:

    Chelioz написал:

    Сколько это в деньгах для циски, лучше даже не знать.

    Ну так если сразу организовать группу, которая занимается разработкой интерфейса и будет соединять внутренние процедуры отвечающие за функционал, написанные другими программистами, с единым интерфейсом командной строки, такой проблемы не будет существовать. Мне кажется у циски процесс производства ПО организован как надо (иначе была бы каша), и там такая группа присутствует, просто накосячили сразу (может ответственный инженер был в отпуске, а не замене был безответственный :) ), или специально сделали (EIGRP все таки же их проприетарный продукт)...

    Но, это все вопрос о том, сколько канадцев нужно чтобы вкрутить лампочку...

    А вообще идея спорная - повышение уровня вложенности = увеличение сложности, а не наоборот, как пишут "мы собрали всю конфигурацию EIGRP в кучу, чтобы облегчить настройку и интерпретацию конфига"
    EIGRP давно открытый, просто никем не реализуемый.
    По поводу процесса разработки, я вам это не с потолка взял, а расписал бюрократические сложности, через которые это всё должно пройти. Ещё раз повторю, я это не придумал. И если кто-то считает, что клёвую идею в большой компании можно реализовать за короткое время, то он наивный дурачок.
    EvgeniyHeine правильно написал, что команды с модулем протокола не так тесно завязаны, но нужно будет привлекать больше одного человека, так как сложность функционала может породить кучу новых багов, просто из-за одной строчки. А это всё трудозатраты, которые вместе с аргументом обратной совместимости и привычек губят идею.

    IOS-XR прекрасен в своей непохожести на IOS. Я бы хотел, чтобы большинство фишек IOX было в IOS. Это очень большая проблема для компании, что её софты не одинаковы. Это плата за покупку чужих идей, за большое количество направлений и попытки исправить корневые проблемы той или иной ОС, сделав новую.
  • a_sa_s
    отредактировано марта 2016

    Точечно прописывается адрес интерфейса, например: 192.168.10.1 0.0.0.0 a 0; 192.168.20.1 0.0.0.0 a 0. Всё, вы точно уверены, что без вашего вмешательства OSPF сам на других интерфейсах не запустится. OSPF смотрит какие интерфейсы покрываются правилом network (в нашем случае только 2 - 10.1 и 20.1) идет на интерфейс, смотрит маску и её уже анонсирует, а не то, что прописано через network. Или запускайте OSPF непосредственно с интерфейса.
    я про то, что и с помощь network можно управлять ospf сетками "точечно". в чем все таки бест практис использования интерфейсных subcommands? Ведь как нам тут заметили в named eigrp все вынесено в один блок, что более наглядно.
  • a_s написал:

    Вроде Cisco в руководствах более предпочитает

    R3 has migrated its configuration away from the
    older network commands, instead using the ip ospf area interface subcommand.
    ospf area interface subcommand , чем router network. Почему? Ведь на первый взгляд видеть ospf сетки в одном месте удобнее?
    Всё равно, лишь бы не смешивать.
    P.S. Если используете network, вводите пожалуйста с wildcard 0.0.0.0, как посоветовали ранее.
  • отредактировано марта 2016
    А чем плохо "точечно" объявлять сеть?
    Например 172.16.32.0 0.0.0.7 ?

  • a_s написал:


    Точечно прописывается адрес интерфейса, например: 192.168.10.1 0.0.0.0 a 0; 192.168.20.1 0.0.0.0 a 0. Всё, вы точно уверены, что без вашего вмешательства OSPF сам на других интерфейсах не запустится. OSPF смотрит какие интерфейсы покрываются правилом network (в нашем случае только 2 - 10.1 и 20.1) идет на интерфейс, смотрит маску и её уже анонсирует, а не то, что прописано через network. Или запускайте OSPF непосредственно с интерфейса.
    я про то, что и с помощь network можно управлять ospf сетками "точечно". в чем все таки бест практис использования интерфейсных subcommands? Ведь как нам тут заметили в named eigrp все вынесено в один блок, что более наглядно.


    В том, что вы лишнего ничего не запустите через интерфейсные команды, а так как вам удобнее и привычнее.
  • отредактировано марта 2016
    feo_sobolev написал:

    А чем плохо "точечно" объявлять сеть?
    Например 172.16.32.0 0.0.0.7 ?

    Не плохо, но идёт в разрез с самой идеей network команды, которая включает OSPF на интерфейсах. Кроме того, нужно помнить маски, чтобы было consistent везде.
    Если мы говорим непосредственно про лабу, то можно быстро собрать IP адреса с помощью "show ip alias" + ALT, и добавить network в начало строки и 0.0.0.0 area 0 в конец строки :)
  • a_sa_s
    отредактировано марта 2016
    cann написал:


    В том, что вы лишнего ничего не запустите через интерфейсные команды, а так как вам удобнее и привычнее.

    dmfigol написал:


    Не плохо, но идёт в разрез с самой идеей network команды, которая включает OSPF на интерфейсах.

    вот. т е можно и с помощью network запускать ospf на определенных интерфейсах. но в отличие от interface subcommands все в одном месте. Правильно понимаю? Но cisco советует subcommands. Почему?


  • a_s написал:

    cann написал:


    В том, что вы лишнего ничего не запустите через интерфейсные команды, а так как вам удобнее и привычнее.

    dmfigol написал:


    Не плохо, но идёт в разрез с самой идеей network команды, которая включает OSPF на интерфейсах.

    вот. т е можно и с помощью network запускать ospf на определенных интерфейсах. но в отличие от interface subcommands все в одном месте. Правильно понимаю? Но cisco советует subcommands. Почему?


    Правильно, просто Cisco не упоминает что можно запускать OSPF с wildcard 0.0.0.0, там везде в примерах ровно по маске сети пишутся через network. Когда вы на интерфейсе пишите, то это происходит более осознанно что-ли и легче читать потом конфигурацию (sh run) и вы точно знаете где у вас OSPF, а где его нет, нежели что-то там прописано через network, да и что-такое network никто не знает и где этот OSPF запущен непонятно. Cisco правильно советует ) К настройке OSPFv3 к тому же не привыкать в будущем. Тут никакого подвоха нет, просто network это т.н. legacy подход, но если используете, то рекомендуется через 0.0.0.0
  • cann написал:

    не привыкать в будущем.

    к томуже BGP использует network команду совсем иначе да?
  • Packo написал:

    cann написал:

    не привыкать в будущем.

    к томуже BGP использует network команду совсем иначе да?
    верно, BGP через network как раз анонсирует то, что прописали, если этот префикс есть в таблице маршрутизации
Войдите или Зарегистрируйтесь чтобы комментировать.