Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 53
Спасибо, много интересных вещей для себя нашел.
Спасибо за интересную статью. Теперь я понял, что не все знаю про статическую маршрутизацию, есть над чем подумать.
Если подключиться к VPN и VPN сервер отдаст дефолт через тоннель
Винда запоминает, через что началось соединение, и будет до упора держать его. Но не стоит сильно полагаться на этот механизм…
У Mikrotik есть такая вещь, как pseudobridge.
Похоже на proxy arp у циски. Если получен arp запрос на адрес, который есть в таблице маршрутизации, то возвращаем запрашивавшему свой мак и маршрутизируем дальнейшие пакеты по FIB. Правда, никаких дополнительных записей не создается (зачем?).
Про Микротик — подозрительно похоже на proxy arp.
Damn, опередили)
Damn, опередили)
Недавно наткнулся на описание работы маршрутизации в современных версиях Windows, тоже довольно интересно и расходится со старыми учебниками:
blogs.technet.com/b/networking/archive/2009/04/24/source-ip-address-selection-on-a-multi-homed-windows-computer.aspx
blogs.technet.com/b/networking/archive/2009/04/24/source-ip-address-selection-on-a-multi-homed-windows-computer.aspx
Как тогда с включенным CEF дебажить пакеты?
1) Локальный capture. Есть под CEF на всех ISR и Catalyst платформах.
2) Сделать ACL вида:
10 permit host A host B log
20 permit ip any any
Это process switch'ит попавший под первую запись пакет, и там, где локальный capture не работает с CEF (Nexus например), трафик посниффить удастся.
Да и вообще, debug ip packet — самый унылый способ анализа трафика из всех.
Ах да — локальный трафик у железки всегда process switch'ится, так что ему CEF не помеха.
2) Сделать ACL вида:
10 permit host A host B log
20 permit ip any any
Это process switch'ит попавший под первую запись пакет, и там, где локальный capture не работает с CEF (Nexus например), трафик посниффить удастся.
Да и вообще, debug ip packet — самый унылый способ анализа трафика из всех.
Ах да — локальный трафик у железки всегда process switch'ится, так что ему CEF не помеха.
Начал читать статью и понял кто автор…
спасибо.
спасибо.
Те неточности, что я увидел
«Наверняка кто-то скажет «из списка локальных интерфейсов», и жестоко ошибется. Маршрутизация так не работает.»
На мой взгляд, человеческая логика так не работает. На основании чего можно брать из списка локальных интерфейсов? Я вот не представляю. Здесь напрашивается только один вывод — запрос к таблице маршутизации — и потом послать arp запрос в соответсвии с ответом
"(хотя у process switching’а множество недостатков помимо неоптимальных запросов – например, постоянное переключение шедулера CPU между контекстами, что весьма затратно)"
Насколько я помню, в IOS платформе нет вытесняющей многозадачности. И нет постоянного переключения CPU между контекстами. Основкым преимуществом CEF была особая структура данных (mtrie), которая позволяет быстро давать нужный ответ — куда пихать пакет (что позволяет в обработчике прерывания обрабатывать пакеты), а process switching — такой структуры нет, и таблица маршрутизации не оптимизирована — то есть на каждый пакет выясняется в какой адрес интерфейс пихать, какие L3 и/или L2 заголовки применять и т.д. и т.п.
«Наверняка кто-то скажет «из списка локальных интерфейсов», и жестоко ошибется. Маршрутизация так не работает.»
На мой взгляд, человеческая логика так не работает. На основании чего можно брать из списка локальных интерфейсов? Я вот не представляю. Здесь напрашивается только один вывод — запрос к таблице маршутизации — и потом послать arp запрос в соответсвии с ответом
"(хотя у process switching’а множество недостатков помимо неоптимальных запросов – например, постоянное переключение шедулера CPU между контекстами, что весьма затратно)"
Насколько я помню, в IOS платформе нет вытесняющей многозадачности. И нет постоянного переключения CPU между контекстами. Основкым преимуществом CEF была особая структура данных (mtrie), которая позволяет быстро давать нужный ответ — куда пихать пакет (что позволяет в обработчике прерывания обрабатывать пакеты), а process switching — такой структуры нет, и таблица маршрутизации не оптимизирована — то есть на каждый пакет выясняется в какой адрес интерфейс пихать, какие L3 и/или L2 заголовки применять и т.д. и т.п.
На основании чего можно брать из списка локальных интерфейсов?
Я сам не знаю. Но нередко слышал такое мнение. И людей реально удивляет, что на самом деле там речь про рекурсивные запросы к тому же самому RIB!
Насколько я помню, в IOS платформе нет вытесняющей многозадачности. И нет постоянного переключения CPU между контекстами.
Я даже специально нашел цитату из книги «Cisco IP Routing: Packet Forwarding and Intra-domain Routing Protocols», автор на тот момент работал инженером эскалации TAC, и явно знает матчасть :) Книжка старая, но не думаю, что с тех времен архитектура IOS стала примитивнее.
Скрытый текст
Why so many switching methods? Why not just go with process switching? We could, if we were not interested in router performance. The main problem with process switching is that the structure of the main routing table in Cisco IOS is not very optimal for fast forwarding—although very convenient for routing protocol operations—and that the packet-processing flow includes too many steps. Consider the following rough outline of events when a packet is received and forwarded by the IP switching process.
1. The I/O controller buffers the frame and sends an IRQ to the CPU.
2. The CPU interrupts the currently running process, changes the execution context, and passes control to the interrupt handler.
3. The interrupt handler takes the buffer from the controller, performs basic checks of the frame, identifies the network protocol, stores the buffer in the corresponding processing queue, and returns control to the interrupted code.
4. The CPU gives control back to the interrupted process.
5. The next time it checks the queue of the pending processes, the IOS scheduler changes the execution context and gives control to the IP switching process, which takes the buffer out of the queue.
6. The IP switching process performs such functions as IpInput(), IpForward(), and IpOutput() and checks the state of the interface output queue. If it is free and the output controller's TX queue is not full, the buffer is submitted directly to the controller; otherwise, it is enqueued into the interface output queue.
7. If the packet has been enqueued into the interface output queue, the router waits for an interrupt from the controller and submits the buffer on it.
In multitasking operating systems, a very expensive task is changing the execution context, whether it is a software or hardware interrupt or process scheduling. The reason is when control is given to another task, a huge number of instructions are carried out to preserve all registers, load the new task's context, and so on. In addition, the CPU memory cache is most probably invalidated. Because of the significant overhead, forwarding packets at the interrupt level when they have just been received might sound reasonable, but the functions used at the process level cannot be just cut and pasted into the code of the interrupt handler. The interrupt handling routines are a special type of code, which needs to be very fast and compact in order to minimize the possibility of nested and lost interrupts, as well as to leave enough time for other tasks. To achieve these characteristics, interrupt handlers are usually coded in a low-level programming language, such as assembler. In addition, performance is increased through use of sophisticated data-processing methods that store and find information more efficiently: information caching, hash functions, radix trees, and so on.
1. The I/O controller buffers the frame and sends an IRQ to the CPU.
2. The CPU interrupts the currently running process, changes the execution context, and passes control to the interrupt handler.
3. The interrupt handler takes the buffer from the controller, performs basic checks of the frame, identifies the network protocol, stores the buffer in the corresponding processing queue, and returns control to the interrupted code.
4. The CPU gives control back to the interrupted process.
5. The next time it checks the queue of the pending processes, the IOS scheduler changes the execution context and gives control to the IP switching process, which takes the buffer out of the queue.
6. The IP switching process performs such functions as IpInput(), IpForward(), and IpOutput() and checks the state of the interface output queue. If it is free and the output controller's TX queue is not full, the buffer is submitted directly to the controller; otherwise, it is enqueued into the interface output queue.
7. If the packet has been enqueued into the interface output queue, the router waits for an interrupt from the controller and submits the buffer on it.
In multitasking operating systems, a very expensive task is changing the execution context, whether it is a software or hardware interrupt or process scheduling. The reason is when control is given to another task, a huge number of instructions are carried out to preserve all registers, load the new task's context, and so on. In addition, the CPU memory cache is most probably invalidated. Because of the significant overhead, forwarding packets at the interrupt level when they have just been received might sound reasonable, but the functions used at the process level cannot be just cut and pasted into the code of the interrupt handler. The interrupt handling routines are a special type of code, which needs to be very fast and compact in order to minimize the possibility of nested and lost interrupts, as well as to leave enough time for other tasks. To achieve these characteristics, interrupt handlers are usually coded in a low-level programming language, such as assembler. In addition, performance is increased through use of sophisticated data-processing methods that store and find information more efficiently: information caching, hash functions, radix trees, and so on.
Хотя есть одна мысль про «На основании чего можно брать из списка локальных интерфейсов?».
Возможно, человеческая логика цепляется за «интерфейс уходит в down, маршрут пропадает — следовательно, маршрут завязывается на интерфейс». Многие ведь действительно не сталкивались с тем, что железка может внезапно найти next hop где-то на стороне.
Возможно, человеческая логика цепляется за «интерфейс уходит в down, маршрут пропадает — следовательно, маршрут завязывается на интерфейс». Многие ведь действительно не сталкивались с тем, что железка может внезапно найти next hop где-то на стороне.
Вот тут и непонятно — как маршрут может завязываться на интерфейс, когда интерфейс вот в таком случае, например, невидно: ip route 10.0.0.0 255.255.255.0 10.1.1.1
И тут логика должна судорожно начать работать, выясняя — каким образом, зная только 10.1.1.1 можно выяснить в какой интерфейс бросить arp запрос. (или уж во все бросать — что уж мелочиться)
И тут логика должна судорожно начать работать, выясняя — каким образом, зная только 10.1.1.1 можно выяснить в какой интерфейс бросить arp запрос. (или уж во все бросать — что уж мелочиться)
Логика-то должна, но не всегда какие-то детали вызывают срабатывание триггера под названием «почему это так?» :)
К написанию этой статьи меня сподвиг данный топик. По словам автора, многие были удивлены тем, что указание ethernet интерфейса без адреса в качестве next hop может быть смертельно опасно…
Более того, даже гуру временами совершают идиотские ошибки.
Так что… Для вас очевидно, что интерфейс получается из рекурсивного запроса к RIB. Для меня тоже. Но поспрашивать сетевиков, многие наверняка в недоумении вытаращатся на вас, они просто никогда не задумывались над тем, откуда берется интерфейс.
Проведите эксперимент, попытайтесь получить точный ответ на вопрос «почему area 0 в OSPF должна быть непрерывной», на уровне обработки LSA ABR'ом. Потом уточните, какое условие должно выполняться, чтобы роутер считал себя ABR. Наверняка тоже удивитесь.
К написанию этой статьи меня сподвиг данный топик. По словам автора, многие были удивлены тем, что указание ethernet интерфейса без адреса в качестве next hop может быть смертельно опасно…
Более того, даже гуру временами совершают идиотские ошибки.
Так что… Для вас очевидно, что интерфейс получается из рекурсивного запроса к RIB. Для меня тоже. Но поспрашивать сетевиков, многие наверняка в недоумении вытаращатся на вас, они просто никогда не задумывались над тем, откуда берется интерфейс.
Проведите эксперимент, попытайтесь получить точный ответ на вопрос «почему area 0 в OSPF должна быть непрерывной», на уровне обработки LSA ABR'ом. Потом уточните, какое условие должно выполняться, чтобы роутер считал себя ABR. Наверняка тоже удивитесь.
А, кстати, почему зона 0 должна быть непрерывной? В RFC про это не сказано.
Рискну предположить, что ABR отбрасывает LSA 3 типа и выше, если не имеет LSA 1 про Advertising Router.
Насчёт условия считания себя ABR в RFC написано, что просто должен принадлежать нескольким зонам. Хотя в Cisco надпись «It is an area border router» не появится, пока не дашь ему ещё и интерфейс в 0 зоне.
Рискну предположить, что ABR отбрасывает LSA 3 типа и выше, если не имеет LSA 1 про Advertising Router.
Насчёт условия считания себя ABR в RFC написано, что просто должен принадлежать нескольким зонам. Хотя в Cisco надпись «It is an area border router» не появится, пока не дашь ему ещё и интерфейс в 0 зоне.
А, кстати, почему зона 0 должна быть непрерывной?
Потому что в ином случае что-то наверняка не будет работать как надо.
ABR отбрасывает LSA 3 типа и выше, если не имеет LSA 1 про Advertising Router.
Нет. Думайте дальше :)
Насчёт условия считания себя ABR
Я немного криво сформулировал вопрос… Перефразирую: при каком условии роутер ведет себя так, что что-то ломает в предыдущем вопросе?
И еще: В RFC2328 как раз сказано «The backbone must be contiguous».
Разумеется, как и в 100500 других источников, которые можно нагуглить. Только вот почему — не написано.
А ответ дан в blog.ine.com/wp-content/uploads/2011/01/Loop-Prevention-in-OSPF.pdf.
Если у роутера есть интерфейс в area 0 (да хоть лупбек), он начинает генерировать LSA 3.
Если у роутера есть поднятое соседство в area 0, он начинает игнорировать LSA 3, пришедшие не от соседей по area 0.
То есть если есть два островка area 0, в каждом из которых хотя бы пара роутеров, и между островками другая area — они не будут обмениваться LSA 3. Но наличие лупбека в area 0 ничего сломать не должно.
Вот и весь ответ :)
Вообще, читайте blog.ine.com, там море бесценной информации.
Если у роутера есть интерфейс в area 0 (да хоть лупбек), он начинает генерировать LSA 3.
Если у роутера есть поднятое соседство в area 0, он начинает игнорировать LSA 3, пришедшие не от соседей по area 0.
То есть если есть два островка area 0, в каждом из которых хотя бы пара роутеров, и между островками другая area — они не будут обмениваться LSA 3. Но наличие лупбека в area 0 ничего сломать не должно.
Вот и весь ответ :)
Вообще, читайте blog.ine.com, там море бесценной информации.
О, классная pdfка, не натыкался на неё там.
Спасибо!
Спасибо!
О да. Лопухов — убергик, и пишет прекрасные вещи.
pavelsh, вот видите? Судя по огромному количеству правильных ответов на вроде бы простой вопрос — никто даже не задумывался над тем, что конкретно мешает нарушить «аксиому» о непрерывности area 0. Хотя по идее этим надо было заинтересоваться сразу же, как только узнаешь, что OSPF может работать в нескольких областях.
pavelsh, вот видите? Судя по огромному количеству правильных ответов на вроде бы простой вопрос — никто даже не задумывался над тем, что конкретно мешает нарушить «аксиому» о непрерывности area 0. Хотя по идее этим надо было заинтересоваться сразу же, как только узнаешь, что OSPF может работать в нескольких областях.
у меня только один вопрос — а зачем это может понадобиться? зачем это делать именно так? =)
p.s. да вы просто мастер в вопросах: как сломать циску и чтобы не сразу было понятно в чем тут дело =) Хотя, конечно, при внимательном изучении такой конфигурации у человека появиться вопрос — а зачем было располагать магистральную зону на островке, когда как тупиковая зона была бы куда логичнее.
p.s. да вы просто мастер в вопросах: как сломать циску и чтобы не сразу было понятно в чем тут дело =) Хотя, конечно, при внимательном изучении такой конфигурации у человека появиться вопрос — а зачем было располагать магистральную зону на островке, когда как тупиковая зона была бы куда логичнее.
1) Если вы не понимаете шестеренки, благодаря которым работает протокол, вы время от времени будете косячить, а также не сможете выдумывать простые и эффективные решения. Например, есть две довольно крупные области, между ними надо гонять трафик, и они пересекаются на одном из роутеров, который не принадлежит к area 0 (а еще и на ABR само собой). И по каким-то причинам нельзя подтащить area 0 поближе к точке их пересечения. Как оптимизировать передачу данных между ними, чтобы пакеты не делали крюк? Ответ — просто создать лупбек и поместить его в area 0.
2) Backbone может развалиться и в результате несчастного случая. Надо точно понимать, чем именно это чревато, а не просто слепо следовать «так делать нельзя, фу-фу-фу».
2) Backbone может развалиться и в результате несчастного случая. Надо точно понимать, чем именно это чревато, а не просто слепо следовать «так делать нельзя, фу-фу-фу».
пока еще не читал пдф, нет времени. Но в сложных случаях предпочитаю использовать ibgp, там больше свободы, хоть и немного сложнее.
iBGP действительно усложнит конфигурацию. И это не отменяет необходимость понимать IGP. Что может быть базовее, чем «почему area 0 должна быть непрерывной»? Ведь вроде простейший вопрос, верно? :)
Я предпочитаю считать, что сетевик должен уметь не только нажимать кнопки строго по инструкции, но и понимать, что у технологии под капотом.
Я предпочитаю считать, что сетевик должен уметь не только нажимать кнопки строго по инструкции, но и понимать, что у технологии под капотом.
Я и не спорил, что человек не должен понимать принципы и алгоритмы, но зачастую от вендора к вендору еще и добавляются разные тонкости реализации, что в итоге несет свои нюансы, желательно все же придерживаться простой и понятной схемы. Ведь даже статическую маршрутизацию умудрились обвязать еще каким-то CEF, ну что за кровавый энтерпрайз?
Если человек работает в многовендорной среде, то он обязан понимать нюансы реализации одного и того же на всём железе всех вендоров.
«Строго по стандарту» — это обычно значит «убого». Любой вендор стремится разработать что-то своё, лучшее, чем стандарт. Хотя бы потому, что это усложняет жизнь клиенту, решившему перейти на другого вендора.
«Строго по стандарту» — это обычно значит «убого». Любой вендор стремится разработать что-то своё, лучшее, чем стандарт. Хотя бы потому, что это усложняет жизнь клиенту, решившему перейти на другого вендора.
![image](http://img2.joyreactor.cc/pics/post/%D0%9A%D0%BE%D0%BC%D0%B8%D0%BA%D1%81%D1%8B-dilbert-588772.png")
Да, согласен с вышеприведенной цитатой. Ничего в ней не противоречит моему знанию классической Cisco IOS. Это я не подумал, что прием каждого пакета порождает прерывание само по себе.
Только смотря на те процессоры, что стоят в старых циско, кажется мне что там не все так драматично, как в современных (вот в современных процессорах переключение контекста — действительно операция мощная). Ну тактов 300-400 на переключение контекста тратиться то точно.
Только смотря на те процессоры, что стоят в старых циско, кажется мне что там не все так драматично, как в современных (вот в современных процессорах переключение контекста — действительно операция мощная). Ну тактов 300-400 на переключение контекста тратиться то точно.
Ну ISRы никогда особо не отличались высокой производительностью… Для гигабитов трафика все равно берут хардварные платформы, где в нормальной ситуации никакой транзитный трафик ни при каких обстоятельствах не заденет ЦП, и уж тем более не будет пунтиться в process switching.
Я не буду говорить про новые аппаратные платформы, но в 3550 когда выжиралась внутренняя память ASIC-а, те маршруты (и/или) ACL падали на процессор, который тут же умирал под трафиком.
То же самое в 3560 и 3750. Ресурс называется TCAM. В логах при этом что-то вроде (случай, когда tcam выжрали аксесс листы)
%ACLMGR-4-ACLTCAMFULL: ACL TCAM Full. Software Forwarding packets on Output label 10 on L3 L2
Ну и есть вещи, которые реализованы изначально только софтверно. Например, на 3560 можно замутить gre тунель. Он даже будет работать, но примерно мегабит через него убьет девайс, если память не изменяет. Убьет в смысле управления и тех вещей, что работают софтверно (icmp, arp).
%ACLMGR-4-ACLTCAMFULL: ACL TCAM Full. Software Forwarding packets on Output label 10 on L3 L2
Ну и есть вещи, которые реализованы изначально только софтверно. Например, на 3560 можно замутить gre тунель. Он даже будет работать, но примерно мегабит через него убьет девайс, если память не изменяет. Убьет в смысле управления и тех вещей, что работают софтверно (icmp, arp).
Убьет в смысле управления
Перегруженный CPU на каталисте — это очень печально по той причине, что на том CPU живут и STP, и протоколы маршрутизации. Может начаться расколбас, когда у железки не останется сил слать кипалайвы.
Вообще же, если говорить про азы маршрутизации, у других вендоров может быть радикально иной взгляд даже на базовые вещи.
Из мануала на телесин (преференс у телесина это та же дистанция для циски — AD).
1. The router inspects the preference value of each candidate route and selects
the route with the lowest preference value.
2. If multiple routes share the lowest preference value, then the router inspects
the metric value of each of these routes and selects the route with the lowest
metric.
3. If multiple routes share the lowest preference and metric values, then the
router inspects the mask of each of these routes and selects the route with
the longest mask.
Т. е. более специфичный статический маршрут (более узкая маска) не перекороет более широкий, но с лучшей дистанцией. Для циски же это будет просто маршрут на другую сеть.
Большой был в свое время сюрприз и неприятный в смысле последствий неверной настройки.
Из мануала на телесин (преференс у телесина это та же дистанция для циски — AD).
1. The router inspects the preference value of each candidate route and selects
the route with the lowest preference value.
2. If multiple routes share the lowest preference value, then the router inspects
the metric value of each of these routes and selects the route with the lowest
metric.
3. If multiple routes share the lowest preference and metric values, then the
router inspects the mask of each of these routes and selects the route with
the longest mask.
Т. е. более специфичный статический маршрут (более узкая маска) не перекороет более широкий, но с лучшей дистанцией. Для циски же это будет просто маршрут на другую сеть.
Большой был в свое время сюрприз и неприятный в смысле последствий неверной настройки.
Само собой я писал только про поведение IOS, причем конкретного IOS, и я наверняка много интересного пропустил (просто такие детали обычно не публикуют и часто меняют). Можно написать по аналогичного размера топику про реализацию той же статики у любого другого вендора.
Ну и да, Cisco, конечно, создает «стандарты», но кто-то их игнорирует, потому надобно тщательно изучать документацию прежде, чем начинать работать с новой железкой.
Ну и да, Cisco, конечно, создает «стандарты», но кто-то их игнорирует, потому надобно тщательно изучать документацию прежде, чем начинать работать с новой железкой.
Эта статья была нужна! Теперь мне есть на что сослаться в следующем выпуске СДСМ.
Топик надо было назвать: особенности статической маршрутизации в Cisco, все же циско — хоть и законодатель моды, но далеко не единственная фирма, выпускающая сетевое оборудование. Да и CEF — это чисто цискинная фича. Или еще можно было топик назвать как: как можно сломать циске мозг при включенном cef =)
Кстати ASR 1к — это разве не софт роутеры?
Больше всего меня волновало в аппаратных платформах циски — это в каких случаях внесение изменений в конфигурацию требует еще каких-либо действий. Например при изменении содержимого некоторых ACL — требуется его убрать с интерфейса и снова добавить, а лучше создать новый ACL и навесить его, а старый удалить. Это из самого простого… Бывалого инженера этим не удивишь, а вот новичка легко в панику бросает, особенно забавно, когда в конфигурацию добавляешь одно, а при чтении конфигурации — видишь совершенно другое (те же активные ACL в isg на 7200, к примеру)… Это так, мысли вслух, вдруг кто захочет статью написать =)
Кстати ASR 1к — это разве не софт роутеры?
Больше всего меня волновало в аппаратных платформах циски — это в каких случаях внесение изменений в конфигурацию требует еще каких-либо действий. Например при изменении содержимого некоторых ACL — требуется его убрать с интерфейса и снова добавить, а лучше создать новый ACL и навесить его, а старый удалить. Это из самого простого… Бывалого инженера этим не удивишь, а вот новичка легко в панику бросает, особенно забавно, когда в конфигурацию добавляешь одно, а при чтении конфигурации — видишь совершенно другое (те же активные ACL в isg на 7200, к примеру)… Это так, мысли вслух, вдруг кто захочет статью написать =)
Топик надо было назвать
Наверное, да… Хотя вроде я ясно дал понять, что статья моновендорная.
Кстати ASR 1к — это разве не софт роутеры?
Нет. Там отдельная логика отвечает за передачу пакетов.
Это так, мысли вслух, вдруг кто захочет статью написать
Вряд ли… 7200 EOL. Современные аппаратные платформы с точки зрения конфигурирования по мере сил унифицируют с программными, они стали очень похожи.
Еще есть вариант «разные источники маршрутов добавляют маршруты на один и тот же префикс с одинаковым AD». Поведение IOS в данном случае не документировано, общая рекомендация – «никогда так делайте».
насколько я помню, если 2 процесса с измененным AD (на одинаковое значение) борются за попадание в таблицу маршрутизации, то IOS смотрит на AD до изменения…
И впрямь, документировано. Не под IOS, но все же.
А если два процесса OSPF или два процесса EIGRP предлагают один и тот же префикс? Говорят, что в случае OSPF выигрывает тот, кто раньше влез в RIB, а у EIGRP — тот, у кого ниже номер AS. Только тут я не видел официального подтверждения.
You can change the administrative distances for routes discovered by or redistributed into a routing protocol. If two routes from two different routing protocols have the same administrative distance, then the route with the lower default administrative distance is entered into the routing table. In the case of EIGRP and OSPF routes, if the EIGRP route and the OSPF route have the same administrative distance, then the EIGRP route is chosen by default.
А если два процесса OSPF или два процесса EIGRP предлагают один и тот же префикс? Говорят, что в случае OSPF выигрывает тот, кто раньше влез в RIB, а у EIGRP — тот, у кого ниже номер AS. Только тут я не видел официального подтверждения.
Еще есть интересный corner case в случае когда маршрут бывает 'connected' и с AD=1. Вроде в статье была оговорка про это. Но на всякий случай если будет интересно статья от конкурентов INE:
blog.ipexpert.com/2012/07/09/old-ccie-myths-static-route-to-the-interface/
blog.ipexpert.com/2012/07/09/old-ccie-myths-static-route-to-the-interface/
IOS создал маршрут, и сразу послал arp запрос в поисках next hop, который у нас – 10.0.0.3.
Первый пакет отбрасывается, и роутер посылает arp запрос с целью узнать mac адрес 10.0.0.3, если он ранее не был известен. CEF же всегда заранее узнает mac адрес next hop'а.
Тащемта дела обстоят так только в 15 IOS, сделайте уж сносочку, что в 12 при добавлении маршрута создаётся запись в FIB с ссылкой на valid glean adjacency (некст хоп указан, но не разрезолвен), затем если под этот префикс попадает пакет, резолвиться next-hop и создаётся valid cached adjacency, которая уже будет висеть, грубо говоря, до скончания веков.
Другое дело если вы до этого nex-hop уже разрезолвили (пинговали или ещё как — случайным бродкастом), то у него уже будет adjacency на момент добавления маршрута, и запись в FIB уже создаться со ссылкой на имеющуюся adjacency.
Что касаемо,
Я не могу представить себе сценарий, когда ожидаемое поведение статического маршрута – переключение на другой интерфейс— вы же сами далее пишите, что стат маршрут может ссылаться на nex-hop получаемый через IGP. Довольно элегантный вариант, на мой взгляд, при ряде условий, и может вылиться как раз в переключение на другой интерфейс. Пример — отсутвие доступа к удаленному маршрутизатору для добавления сети находящейся за ним в анонс IGP.
Тащемта дела обстоят так только в 15 IOS
По-моему, и в 12-х ветках уже немало времени было такое же поведение (если мы говорим о каталистах). Но проверю.
Говорить о поведении 12-х веток для роутеров в рамках этой статьи было бы странно, из продакшна они уже потихоньку начинают исчезать. И я не ставил себе целью рассказать о CEF глубже чем по самым верхам (кроме меня про существование CEF вообще никто из авторов статей не вспоминал).
Да и в начале я написал "… на IOS линейки 15.2M. Поведение других ОС может различаться".
Пример — отсутвие доступа к удаленному маршрутизатору для добавления сети находящейся за ним в анонс IGP.
Это как раз из разряда «я не могу представить себе такой сценарий». В академических целях пример остроумный, на практике — если на роутере сломали aaa, то новая сеть обождет, есть более важная проблема
[из подвала раздаются вопли того, кто внес изменение в настройки aaa, не проверив сразу же его корректность в отдельной сессии]
Говорить о поведении 12-х веток для роутеров в рамках этой статьи было бы странно, из продакшна они уже потихоньку начинают исчезать.
Ну до исчезания ещё лет 5, я думаю, многие еще 15 и не щупали, и это оправданно по крайней мере с точки зрения затрат на переход.
И я не ставил себе целью рассказать о CEF глубже чем по самым верхам (кроме меня про существование CEF вообще никто из авторов статей не вспоминал).
Ну ставили не ставили, а по факту утверждаете, что вот оно отличие CEF`а, хотя по факту это отличие 15ого IOS`а.
если на роутере сломали aaa, то новая сеть обождет, есть более важная проблема
Ну нет же. Скорее, в dualhomed/multihomed BGP когда uplink провайдеры анонсируют вам дефолт и directed connected AS, а вам хотелось бы добавить ещё и маршрут на сеть находящуюся за directed connected AS (за два хопа от вас), что бы соптимизировать роутинг.
в dualhomed/multihomed BGP когда uplink провайдеры анонсируют вам дефолт и directed connected AS
Такого не встречал. Обычно дают просто дефолт, хотя, наверное, договориться можно. Если есть и другие, уникальные для каждого провайдера префиксы, то можно создать по статике с треками, отслеживающими наличие каждого из префиксов. Чуть больше конфигурации, но зато более прозрачная схема.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
А вы хорошо знаете статическую маршрутизацию?