Comments 43
предложения не было – ни одного подкаста в этой сфере.
Рекомендую packetpushers.net/category/podcast-post :)
По поводу ip routing. На самом деле (в случае ethernet) интерфейс указывать стоит вместе с next hop'ом. Упражнение: что будет, если физический интерфейс, на котором изначально был next hop, перейдет в down, а откуда-нибудь со стороны прилетит анонс по IGP на содержащую next hop сеть?
Спасибо, Дима.
Ты не перестаёшь удивлять своей осведомлённостью)
Ты не перестаёшь удивлять своей осведомлённостью)
Грабли, шишки на лбу…
ip route… permanent не даст пропасть маршруту при дауне интерфейса
То есть вы подумали, что при наличии маршрута:
и интерфейса:
переход интерфейса fa0/0 в down автоматически означает пропадание роута? Но это не так :)
И тот факт, что это не так, способен вызвать проблемы в определенных сценариях — когда на самом деле надо, чтобы маршрут пропал из таблицы маршрутизации.
ip route 10.0.0.0 255.255.255.0 192.168.0.1
и интерфейса:
int fa0/0
ip address 192.168.0.2 255.255.255.252
переход интерфейса fa0/0 в down автоматически означает пропадание роута? Но это не так :)
И тот факт, что это не так, способен вызвать проблемы в определенных сценариях — когда на самом деле надо, чтобы маршрут пропал из таблицы маршрутизации.
Хм. permamnet описывается как «Specifies that the route will not be removed, even if the interface shuts down»
Т.е. это относится к случаям, когда маршрут не на ип, а на интерфейс указан? Или как тогда понимать это описалово параметра.
Т.е. это относится к случаям, когда маршрут не на ип, а на интерфейс указан? Или как тогда понимать это описалово параметра.
Вы все правильно понимаете, но проблема-то как раз в том, что если линк, где находится next hop, падает, маршруту следовало бы покинуть таблицу маршрутизации, но он вовсе не всегда это делает, перенацеливаясь в другую сторону и создавая L3 луп для указанного префикса :) Как тут поможет permanent?
А в каких случаях он этого не делает? Сколько раз я ни сталкивался с такой ситуацией — при падении интерфейса из таблицы удаляется маршрут, если эта сеть была directly connected.
Если из примера дмитрия фа0 задаунить, но при этом будет существовать маршрут на 192.168.0.0 (он может быть даже не по IGP придет, а может уже присутствовать как защитный статик с более широкой маской), то исходный ip route 10.0.0.0 255.255.255.0 192.168.0.1 не исчезнет.
Ну к примеру есть железка, у которой есть маршрут:
Где-то далеко.
Я ввожу левый статический маршрут:
Т.е. next hop вовсе не connected.
Смотрим таблицу маршрутизации:
Маршрут есть.
Смотрим CEF:
Т.е. ответ: статический маршрут дает железке next hop к префиксу, и если в самом маршруте не указан явным образом интерфейс, то железка выполняет рекурсивный запрос к таблице маршрутизации в поисках next hop'а к next hop'у. Если потребуется — несколько раз подряд. Надеюсь, понятно, что в 99,999% случаев такое поведение нежелательно?
А теперь кто скажет, что будет на уровне IGP с маршрутом на префикс 1.1.1.0/24, если сказать «redistribute static»? :)
Если надо, могу вечерком нарисовать топологию, в которой факт непропадания маршрута из таблицы маршрутизации ломает доступ к 1.1.1.0/24.
А был ли он connected на какой-то момент времени — не имеет никакого значения.
D 10.0.46.0/24 [90/3072] via 10.0.0.4, 6w1d, GigabitEthernet0/1
Где-то далеко.
Я ввожу левый статический маршрут:
R00(config)#ip route 1.1.1.0 255.255.255.0 10.0.46.1
Т.е. next hop вовсе не connected.
Смотрим таблицу маршрутизации:
S 1.1.1.0 [1/0] via 10.0.46.1
D 10.0.46.0/24 [90/3072] via 10.0.0.4, 6w1d, GigabitEthernet0/1
Маршрут есть.
Смотрим CEF:
R00#show ip cef 1.1.1.1 detail
1.1.1.0/24, epoch 0
recursive via 10.0.46.1
recursive via 10.0.46.0/24
nexthop 10.0.0.4 GigabitEthernet0/1
Т.е. ответ: статический маршрут дает железке next hop к префиксу, и если в самом маршруте не указан явным образом интерфейс, то железка выполняет рекурсивный запрос к таблице маршрутизации в поисках next hop'а к next hop'у. Если потребуется — несколько раз подряд. Надеюсь, понятно, что в 99,999% случаев такое поведение нежелательно?
А теперь кто скажет, что будет на уровне IGP с маршрутом на префикс 1.1.1.0/24, если сказать «redistribute static»? :)
Если надо, могу вечерком нарисовать топологию, в которой факт непропадания маршрута из таблицы маршрутизации ломает доступ к 1.1.1.0/24.
А был ли он connected на какой-то момент времени — не имеет никакого значения.
Попробовал, вроде понятно. Дауним интерфейс. Но его подсеть начинает роутиться куда-то в другое место. От того, что маршрут на нехт-хоп не пропал и исходный маршрут не исчезает. Вроде так. Тогда ключевое слово перманент получается актуально только в том случае, когда интерфейс в дауне, маршрутов на нехт-хоп нету и тогда перманент не дает статик роуту слинять… Поправьте, если это не так.
Тогда ключевое слово перманент получается актуально только в том случае, когда интерфейс в дауне
Вы все правильно понимаете, но permanent никак не решит проблему «маршрут не исчезает, когда интерфейс с ожидаемым next hop'ом переходит в down», скорее наоборот — усугубит. Он уж почти гарантирует, что железка не станет пользоваться резервными путями для доступа к префиксу, или воспользуется неправильными путями.
Тогда сформулирую иначе. Когда он (перманент) нужен? При каком сценарии? То, что в приведенном выше примере ситуация усугубляется — понятно. Я уже отказался от идеи, что так ситуацию можно решить. Я второй частью своего текста «гда ключевое слово перманент получается актуально только ...» уже не рассматриваю изначальный пример, а пытаюсь понять, когда вообще этот перманент нужен. В общем, так скажем, случае. Ведь при таком хитром поведении не понятно, зачем городить огород для НЕпропадания маршрута, если ему и так очень сложно пропасть. В сложной сети описанный пример с «прилетанием» маршрута, охватывающего некст-хоп совсем не редкость.
Тогда сформулирую иначе. Когда он (перманент) нужен?
Единственное, что приходит в голову — сценарий «когда нет пути через указанный интерфейс, то нульрутить». Так как это будет аналог нульрута, одной строчкой вместо двух (но не зная шестеренки внутри каждой конкретной железки — не могу гарантировать, что прибитый таким образом трафик не будет пунтиться на CPU, надо смотреть).
Зачем так делать? Понятия не имею.
Я никогда не пользовался ключевым словом permanent.
Хм.
supportforums.cisco.com/thread/194350
Sure. Sometimes it is «better» to have a more stable network than it is to have exact precision in your routing table. One scenario: you have some destinations for which you have static routes which you redistribute into your dynamic protocol. And you have some remote locations where you do not want to consume bandwidth with routing updates that you could avoid or you have some routers where you do not want routing updates and convergence to chew up CPU cycles if you can avoid it. So you configure your static routes as permanent. They always stay in the routing table, no bandwidth used for routing updates, no CPU cycles for convergence. The downside is that some traffic gets sent to you that you can not forward and must discard.
Second scenario: probably even more common. You are running BGP with multiple service providers. You have some static routes in your routing table so that the BGP network statements will have a match. To prevent flapping of your advertisements to the providers you want the static route to always be present in the routing table. (Of course many of us accomplish this with static routes to null 0 — but the static permanent is another alternatie).
supportforums.cisco.com/thread/194350
Sure. Sometimes it is «better» to have a more stable network than it is to have exact precision in your routing table. One scenario: you have some destinations for which you have static routes which you redistribute into your dynamic protocol. And you have some remote locations where you do not want to consume bandwidth with routing updates that you could avoid or you have some routers where you do not want routing updates and convergence to chew up CPU cycles if you can avoid it. So you configure your static routes as permanent. They always stay in the routing table, no bandwidth used for routing updates, no CPU cycles for convergence. The downside is that some traffic gets sent to you that you can not forward and must discard.
Second scenario: probably even more common. You are running BGP with multiple service providers. You have some static routes in your routing table so that the BGP network statements will have a match. To prevent flapping of your advertisements to the providers you want the static route to always be present in the routing table. (Of course many of us accomplish this with static routes to null 0 — but the static permanent is another alternatie).
no CPU cycles for convergence
Об этом уж точно можно не заботиться. IGP куда больше ресурсов потребует даже на кипалайвы. Разве что какой интерфейс сильно флапится, но на это можно (и нужно) ответить dampening'ом.
You have some static routes in your routing table so that the BGP network statements will have a match.
Только я подумал об очевидном и общепринятом решении этой задачи, как в последнем предложении его упомянули.
Боюсь ошибиться, но может быть когда за одни интерфесом используеться несколько сетей с разными адресациями не входящими непосредственно в адресацию интерфейса?
Все статические маршруты на одинаковый next hop, т.е.:
ip route x.x.x.0 255.255.255.0 10.0.0.1
ip route y.y.y.0 255.255.255.0 10.0.0.1
и так далее будут ложиться или подниматься одновременно, в зависимости от достижимости 10.0.0.1. Если он недоступен, то статическому маршруту лучше бы покинуть таблицу маршрутизации — толку от него все равно не будет.
Или речь про широковещательный сегмент, напрямую висящий за интерфейсом, где у разных групп устройств разные подсети? В таких случаях назначают secondary адрес.
ip route x.x.x.0 255.255.255.0 10.0.0.1
ip route y.y.y.0 255.255.255.0 10.0.0.1
и так далее будут ложиться или подниматься одновременно, в зависимости от достижимости 10.0.0.1. Если он недоступен, то статическому маршруту лучше бы покинуть таблицу маршрутизации — толку от него все равно не будет.
Или речь про широковещательный сегмент, напрямую висящий за интерфейсом, где у разных групп устройств разные подсети? В таких случаях назначают secondary адрес.
Или речь про широковещательный сегмент, напрямую висящий за интерфейсом, где у разных групп устройств разные подсети? В таких случаях назначают secondary адрес.
да именно про это. а если адресаций больше 2-х?
а если есть не одна точка входа в сеть, а больше? и точки связаным между друг другом с помощью динамической маршрутизации, и нельзя допустить что бы при пропадании интерфейса трафик шел через другие хопы, а просто дропался?
понимаю что уже попахивает бредом и в реальности это будет огород из костылей и велосипедов, но можно же так извратиться:)
да именно про это. а если адресаций больше 2-х?
а если есть не одна точка входа в сеть, а больше? и точки связаным между друг другом с помощью динамической маршрутизации, и нельзя допустить что бы при пропадании интерфейса трафик шел через другие хопы, а просто дропался?
понимаю что уже попахивает бредом и в реальности это будет огород из костылей и велосипедов, но можно же так извратиться:)
а если адресаций больше 2-х?
Навесить больше двух secondary…
А без них как вы собираетесь принимать входящий трафик от расположенных там хостов? Кого укажете в качестве первого хопа?
Еще проблема: если есть маршрут вида ip route 192.168.0.0 255.255.255.0 vlan100, то роутер наверняка пошлет arp request со своего адреса из другой подсети — но я чертовски сомневаюсь, что клиент отправит reply на явную липу.
(да, статья говорит «так делать не надо», но я говорю «для небольших сеток так делать плохо, но не очень вредно»)
а если есть не одна точка входа в сеть, а больше? и точки связаным между друг другом с помощью динамической маршрутизации, и нельзя допустить что бы при пропадании интерфейса трафик шел через другие хопы, а просто дропался?
Вы не сможете поднять соседство по IGP с помощью secondary адреса. А несколько VLANов или сабов завести религия не позволяет? :)
Без хоть какого-то адреса на интерфейсе не получится, собственно, устроить двухстороннее общение между хостами одновременно в разных подсетях.
Впрочем, у меня уже взорван мозг, так что я не понял фразу «нельзя допустить что бы при пропадании интерфейса трафик шел через другие хопы, а просто дропался?» — если речь идет про IGP, то зачем статика? Связность нарушена => трафик не идет, так как нет обмена маршрутами.
«но я чертовски сомневаюсь, что клиент отправит reply на явную липу»
Никаких проблем. Что помешает? Я даже больше скажу. В вин2008 периодически наблюдаю попытки прорезолвить виндой по arp ипшники из радикально чужой подсети.
C:\>ipconfig
Настройка протокола IP для Windows
Подключение по локальной сети — Ethernet адаптер:
DNS-суффикс этого подключения..:…
IP-адрес............: 10.16.1.217
Маска подсети..........: 255.255.255.224
Основной шлюз..........: 10.16.1.193
10:40:05.344028 arp who-has 10.16.1.217 (00:0c:29:a0:99:f8) tell 10.16.2.1
10:40:05.344043 arp reply 10.16.1.217 is-at 00:0c:29:a0:99:f8
Никаких проблем. Что помешает? Я даже больше скажу. В вин2008 периодически наблюдаю попытки прорезолвить виндой по arp ипшники из радикально чужой подсети.
C:\>ipconfig
Настройка протокола IP для Windows
Подключение по локальной сети — Ethernet адаптер:
DNS-суффикс этого подключения..:…
IP-адрес............: 10.16.1.217
Маска подсети..........: 255.255.255.224
Основной шлюз..........: 10.16.1.193
10:40:05.344028 arp who-has 10.16.1.217 (00:0c:29:a0:99:f8) tell 10.16.2.1
10:40:05.344043 arp reply 10.16.1.217 is-at 00:0c:29:a0:99:f8
Буду знать :)
А раз так… Статическая arp запись у клиента на 10.16.1.193 (даже если такого IP адреса у роутера нет, но есть мак в нужном VLANе) — и транзитный трафик вполне будет ходить через роутер… Да и в принципе, arp reply от клиента тоже не особенно нужен, так как и на роутере можно статику создать… Нет, это абсолютно кошмарно, так делать нельзя, но оно может работать.
А раз так… Статическая arp запись у клиента на 10.16.1.193 (даже если такого IP адреса у роутера нет, но есть мак в нужном VLANе) — и транзитный трафик вполне будет ходить через роутер… Да и в принципе, arp reply от клиента тоже не особенно нужен, так как и на роутере можно статику создать… Нет, это абсолютно кошмарно, так делать нельзя, но оно может работать.
Чего только в малых провайдерских сетях не насмотришься. Выпиливание лобзиком лаукост решений (рабочих, что самое интересное) — интересная и ностальгическая тема.
Вот про то, что ваяли на основе arp пионернеты еще сравнительно недавно.
nag.ru/articles/article/16988/upravlyaem-neupravlyaemyim.html
Вот про то, что ваяли на основе arp пионернеты еще сравнительно недавно.
nag.ru/articles/article/16988/upravlyaem-neupravlyaemyim.html
Линукс тоже ниче против такого запроса не имеет
10:47:42.340969 ARP, Request who-has 192.168.10.1 (00:0c:29:90:4d:6a) tell 10.16.2.1, length 28
10:47:42.352337 ARP, Reply 192.168.10.1 is-at 00:0c:29:90:4d:6a, length 46
10:47:42.340969 ARP, Request who-has 192.168.10.1 (00:0c:29:90:4d:6a) tell 10.16.2.1, length 28
10:47:42.352337 ARP, Reply 192.168.10.1 is-at 00:0c:29:90:4d:6a, length 46
Кстати, любителям всяких извращений рекомендую прочитать книгу (вроде бы) нашего соотечественника, знающего примерно всё про шестеренки, благодаря которым работают IGP (да и статический роутинг) — www.amazon.com/Cisco-Routing-Forwarding-Intra-domain-Protocols/dp/0201604736/. Эта книга устарела, часть сказанного в ней неверно в случае современных версий IOS, но в целом она дает весьма глубокое понимание устройства IOS по части маршрутизации. Многие вопросы отпадут.
И кстать, а если есть дефолт роут? Т.е. в вашем примере некст хоп 10.0.46.1 доступен через статический 0.0.0.0? Тот же эффект?
+1 за packetpushers. Местами бывает реальный хардкор =)
Ну там ого-го какие люди приглашаются…
Вот за это я его и люблю =) Да и ведущие тоже отменные.
Надеюсь ЛинкМиАп тоже с гостями не подкачает ;)
Надеюсь ЛинкМиАп тоже с гостями не подкачает ;)
Я прямо сейчас слушаю ЛинкМиАп — очень даже неплохо. Много новых слов узнаю. Действительно грамотно сделано. Ну авось через годик сам Dino будет отвечать на их вопросы про LISP :)
Кстати: а периодически играющая в фоне музыка — это чей-то забытый мобильник (такое ощущение, что слышится виброзвонок), или фича? Если фича, то лучше бы переделать, так как уж очень на баг смахивает и несколько отвлекает.
Кстати: а периодически играющая в фоне музыка — это чей-то забытый мобильник (такое ощущение, что слышится виброзвонок), или фича? Если фича, то лучше бы переделать, так как уж очень на баг смахивает и несколько отвлекает.
А когда в ITunes вас ждать?
Переадресую вопрос eucariot, ибо я не в теме.
Не задумывался даже об этом. Спасибо за идею. Постараюсь следующий выпуск уже туда.
Только вот что-то в последнее время они на DC и все что вокруг него зациклились. Раньше было разнообразнее.
А если там будет VTI с ip unnumbered?
Спасибо, было интересно послушать. Хорошая инициатива, надесь у вас хватит энтузиазма надолго.
По ходу подкаста я понял, что вы все живете в разных городах, но при этом все неплохо знакомы. Как это случилось, есть какая-то телекомовская тусовка про которую я не знаю?
По ходу подкаста я понял, что вы все живете в разных городах, но при этом все неплохо знакомы. Как это случилось, есть какая-то телекомовская тусовка про которую я не знаю?
Спасибо большое, послушал с большим интересом. Жду следующих выпусков.
Не хватает вам по радиочасти кого-нибудь только :) Хэндоверы, инициируемые трубкой это что-то новое :)
Не хватает вам по радиочасти кого-нибудь только :) Хэндоверы, инициируемые трубкой это что-то новое :)
Sign up to leave a comment.
LinkMeUp. Выпуск 0