Comments 204
А про ИП на loopback (127.0.0.1—127.255.255.255) забыто, а ведь многие не знают (даже добавляя в hosts записи, что бы программы не могли активироваться).
Что именно не знают, кроме того что там диапазон 127..0/8
Можно например по. Rdp подключится сам на любой loopback кроме 127.0.0.1, так же некоторые сервисы при обращении на свой же хост используют не .1, а адрреса из этой сети
Можно например по. Rdp подключится сам на любой loopback кроме 127.0.0.1, так же некоторые сервисы при обращении на свой же хост используют не .1, а адрреса из этой сети
Да кроме 127/8 есть еще куча специальных диапазонов (см. rfc3330). Но это все другой уровень.
Да и конкретно в отношении этого блока… когда вы последний раз видели лупбек с адресом из этого блока, но не 127.0.0.1/8? Я в своей жизни видел одну технологию, которая использует такие адреса, но… не было б ее, и мало что изменилось в жизни. Так что, в сущности, просрали один /8 на какую-то фигню.
Лупбеки в реальной жизни нумеруют либо /32 из реальных адресов, либо /N, например, при выдаче ШПД-абонентам с BRAS из большого блока. Но это все ни полраза не ликбез.
Да и конкретно в отношении этого блока… когда вы последний раз видели лупбек с адресом из этого блока, но не 127.0.0.1/8? Я в своей жизни видел одну технологию, которая использует такие адреса, но… не было б ее, и мало что изменилось в жизни. Так что, в сущности, просрали один /8 на какую-то фигню.
Лупбеки в реальной жизни нумеруют либо /32 из реальных адресов, либо /N, например, при выдаче ШПД-абонентам с BRAS из большого блока. Но это все ни полраза не ликбез.
/8 может и зря просрали, но меньше /16 все равно не стоило бы, imnsho. Я, к примеру, на очень маленьком и скромненьком freebsd-сервере раздал несколько loopback-адресов jail'ам. Потому что было надо, да.
У нас активно используется для внутренней адресации бэкендов внешних сервисов. Без /8 выкрутились бы, наверное, но такими методами, что ну его нафиг.
а чем 10/8 для этих же целей не устраивает?
Произвольные адреса из 10/8 могут использоваться для адресации внутри тоннелей до тех клиентов, у которых 10/8 в корпоративной сети. А нужен был блок адресов, который можно автоматизированно и относительно бездумно аллоцировать для внутренней адресации.
Я хочу уточнить предыдущий комментарий: лично нам именно /8 необязателен, хватило бы 127/17. Но в контексте вопроса «когда вы последний раз видели лупбек с адресом из этого блока, но не 127.0.0.1/32» это не так важно. Видели, и много.
Я хочу уточнить предыдущий комментарий: лично нам именно /8 необязателен, хватило бы 127/17. Но в контексте вопроса «когда вы последний раз видели лупбек с адресом из этого блока, но не 127.0.0.1/32» это не так важно. Видели, и много.
Ну тогда стоит еще вспомнить о link-local адресах…
очень познавательно, спасибо
Спасибо, кеп. Плюсанул.
>> Из сказанного в частности следует, что маршрутизатор (шлюз и маршрутизатор — это одно и то же) с адресом интерфейса 192.168.8.1 ничего не знает о трафике, передаваемом между, например, хостами 192.168.8.5 и 192.168.8.7.
Но тем не менее можно настроить, чтобы весь траффик шёл через шлюз, а хосты об этом и знать ничего не будут. С помощью специальных железяк. Хотя конечно в статье об этом можно не упоминать.
>> Адрес 192.168.8.0, со всеми обнуленными битами на позициях, соответствующих нулям в маске, называется адресом подсети. Его (обычно) нельзя использовать в качестве адреса для интерфейса того или иного хоста.
Если обычно нельзя, то когда можно?
>> Если же эти биты наоборот, установить в единицы, то получится адрес 192.168.15.255. Этот адрес называется направленным бродкастом (широковещательным) для данной сети. Смысл его по нынешним временам весьма невелик: когда-то было поверье, что все хосты в подсети должны на него откликаться, но это было давно и неправда.
Но он работает так до сих пор, или же это уже не работает?
Но тем не менее можно настроить, чтобы весь траффик шёл через шлюз, а хосты об этом и знать ничего не будут. С помощью специальных железяк. Хотя конечно в статье об этом можно не упоминать.
>> Адрес 192.168.8.0, со всеми обнуленными битами на позициях, соответствующих нулям в маске, называется адресом подсети. Его (обычно) нельзя использовать в качестве адреса для интерфейса того или иного хоста.
Если обычно нельзя, то когда можно?
>> Если же эти биты наоборот, установить в единицы, то получится адрес 192.168.15.255. Этот адрес называется направленным бродкастом (широковещательным) для данной сети. Смысл его по нынешним временам весьма невелик: когда-то было поверье, что все хосты в подсети должны на него откликаться, но это было давно и неправда.
Но он работает так до сих пор, или же это уже не работает?
>Но он работает так до сих пор, или же это уже не работает?
интересно, а как маршрутизатор узнаёт какой ip адрес соответствует какому MAC адресу…
Из текста я понял только что автор не «начинающий администратор», а совсем даже «уважающий себя администратор».
интересно, а как маршрутизатор узнаёт какой ip адрес соответствует какому MAC адресу…
Из текста я понял только что автор не «начинающий администратор», а совсем даже «уважающий себя администратор».
ARP, который определяет mac для ip, работает поверх ethernet, а не ip. И ему в общем-то все равно, какой широковещательный адрес у сети, он шлет сообщения только по маку (ff:ff:ff:ff:ff:ff).
Широковещательный адрес сети можно использовать для, например, пинга всех хостов сразу. Но немногие системы на такое отвечают, и в моей сети на такой пинг ответил только шлюз.
Широковещательный адрес сети можно использовать для, например, пинга всех хостов сразу. Но немногие системы на такое отвечают, и в моей сети на такой пинг ответил только шлюз.
1. Не так часто, когда такое «можно настроить» нужно использовать в жизни. Иногда да, надо, но в большинстве случаев этим занимаются господа, знающие толк в извращениях.
2. В статье есть ответ на этот вопрос. См. про p2p-линки с масками /31.
3. В принципе директ-бродкаст до сих пор теоретически используется. Например в приложении wake-on-lan. Но, вообще говоря, нет проблем переписать такие приложения (не знаю, но думаю, что скорее всего уже) под использование, например, мультикаста. Я лично не видел ни одной живой сети, где на директ-бродкаст что-то возлагали. В любом случае негативный эффект от выкидывания адресов на помойку не сравним с преимуществами, которые дает направленный бродкаст.
2. В статье есть ответ на этот вопрос. См. про p2p-линки с масками /31.
3. В принципе директ-бродкаст до сих пор теоретически используется. Например в приложении wake-on-lan. Но, вообще говоря, нет проблем переписать такие приложения (не знаю, но думаю, что скорее всего уже) под использование, например, мультикаста. Я лично не видел ни одной живой сети, где на директ-бродкаст что-то возлагали. В любом случае негативный эффект от выкидывания адресов на помойку не сравним с преимуществами, которые дает направленный бродкаст.
> Я лично не видел ни одной живой сети, где на директ-бродкаст что-то возлагали.
Ну-ну. А как хост, включенный в сеть, находит там DHCP-сервер, чтобы получить с него сетевые настройки? Делает он это именно через UDP-броадкаст на IP-адрес 255.255.255.255.
DHCPDISCOVER:
UDP Src=0.0.0.0 sPort=68 Dest=255.255.255.255 dPort=67
Т.е. вы «лично не видели ни одной живой сети» с DHCP-сервером?
Ну-ну. А как хост, включенный в сеть, находит там DHCP-сервер, чтобы получить с него сетевые настройки? Делает он это именно через UDP-броадкаст на IP-адрес 255.255.255.255.
DHCPDISCOVER:
UDP Src=0.0.0.0 sPort=68 Dest=255.255.255.255 dPort=67
Т.е. вы «лично не видели ни одной живой сети» с DHCP-сервером?
Не, не. Давайте на пальцах. Вот я, например, покупаю дешевый пассивный свич на 5 портов для квартирной сетки. Адреса выставляю на компах вручную, диапазон 192.168.0.0/24. Соотвественно вопросы:
* Если я дам компам адреса 192.168.0.0 и 192.168.0.255 оно будет работать.
* А если я пошлю с 192.168.0.1 пинг на 192.168.0.255 мне все компы ответят? А если есть/нет хоста с таким адресом в сети?
* Если я дам компам адреса 192.168.0.0 и 192.168.0.255 оно будет работать.
* А если я пошлю с 192.168.0.1 пинг на 192.168.0.255 мне все компы ответят? А если есть/нет хоста с таким адресом в сети?
1. Зависит от реализации (и настройки) стека на конкретных устройствах, но с большой вероятностью нет.
2. То же самое. Скорее всего нет.
2. То же самое. Скорее всего нет.
То есть, если у меня не активный свитч или что покруче, то 2 адреса для меня всегда закрыты для использования?
Ой, слушайте, спросите в гугле, чем свич от роутера отличается, а то я устал, если честно )
Адреса подсетей (все нули в хостовой части) и бродкастов (все единицы) нельзя использовать в качестве адресов компьютеров. В случае с серыми адресами это и не является проблемой, т. к. их много.
Адреса подсетей (все нули в хостовой части) и бродкастов (все единицы) нельзя использовать в качестве адресов компьютеров. В случае с серыми адресами это и не является проблемой, т. к. их много.
Ан нет. Раз уж взялись объяснять, то будьте добры.
Впрочем у меня к вам больше вопросов нет.
Впрочем у меня к вам больше вопросов нет.
Простите, я таки задам вопрос, с вашего позволения.
Правильно ли я понял? Адреса подсетей и бродкастов (эти же подсетей) можно использоваться только между линками L3.
… пока писал вопрос сам понял свою глупость, какие IP адреса могут быть на L2 %)
В таком случае, если в ситуации описанной qnomeby при отправки пинга с 192.168.0.1 на 192.168.0.255 первый хост отправит широковещательный пинг на ffff.ffff.ffff?
Правильно ли я понял? Адреса подсетей и бродкастов (эти же подсетей) можно использоваться только между линками L3.
… пока писал вопрос сам понял свою глупость, какие IP адреса могут быть на L2 %)
В таком случае, если в ситуации описанной qnomeby при отправки пинга с 192.168.0.1 на 192.168.0.255 первый хост отправит широковещательный пинг на ffff.ffff.ffff?
Зависит от конкретного пинга. В линуксе пинг говорит следующее
Опция -b заставляет отправлять это на MAC из всех единиц (доступно руту).
Отвечает на него один из двух принтеров. Даже не принтер, а HP-шная коробочка принт-сервер.
JUNOS-based устройства Juniper, Cisco IOS (тоже из-под enable) и Brocade NetIron ничего не спрашивая сразу шлют на бродкастовый MAC.
Некоторые другие имеющиеся в моем распоряжении устройства тупо спрашивают ARP «who is x.x.x.255». Среди них SreenOS-based файрволы Juniper.
Но пинг с машины, которая сама знает, что адрес бродкастовый — это еще полбеды. Куда сложнее вопрос, как обрабатывать транзитный трафик. Допустим вы пингуете адрес 10.0.0.63. Вы ничего не знаете, как оно там где-то побито. Дошло все до маршрутизатора, у которого есть интерфейс 10.0.0.1/26. Чего ему делать?
Весьма допотопная RFC1812 как бе намекает нам: «Чо хошь, то и делай»:
user@host:~$ ping x.x.x.255
Do you want to ping broadcast? Then -b
Опция -b заставляет отправлять это на MAC из всех единиц (доступно руту).
Отвечает на него один из двух принтеров. Даже не принтер, а HP-шная коробочка принт-сервер.
JUNOS-based устройства Juniper, Cisco IOS (тоже из-под enable) и Brocade NetIron ничего не спрашивая сразу шлют на бродкастовый MAC.
Некоторые другие имеющиеся в моем распоряжении устройства тупо спрашивают ARP «who is x.x.x.255». Среди них SreenOS-based файрволы Juniper.
Но пинг с машины, которая сама знает, что адрес бродкастовый — это еще полбеды. Куда сложнее вопрос, как обрабатывать транзитный трафик. Допустим вы пингуете адрес 10.0.0.63. Вы ничего не знаете, как оно там где-то побито. Дошло все до маршрутизатора, у которого есть интерфейс 10.0.0.1/26. Чего ему делать?
Весьма допотопная RFC1812 как бе намекает нам: «Чо хошь, то и делай»:
Directed Broadcast - a broadcast directed to the specified
network prefix. It MUST NOT be used as a source address. A
router MAY originate Network Directed Broadcast packets. A
router MUST receive Network Directed Broadcast packets; however
a router MAY have a configuration option to prevent reception
of these packets. Such an option MUST default to allowing
reception.
Задать адреса 192.168.0.0/24 или 192.168.0.255/24 вам не позволит ОС (если это не какая-то редкая непонятная ОС, не соблюдающая стандарты).
На пинг с адреса 192.168.0.1 на 192.168.0.255 в сети 192.168.0.0/24 ответят все работающие интерфейсы в этой сети.
Кроме того, большинство хостов считают адрес самой сети 192.168.0.0 также её броадкастовым адресом, поэтому если пропинговать 192.168.0.0, то на него тоже скорее всего ответят все работающие интерфейсы (но это не обязательно).
Если пропинговать 192.168.0.255 из какой-нибудь другой сети, например из 10.0.0.0/24 то ICMP-пакеты скорее всего отбросятся на ближайшем маршрутизаторе, т.к. по умолчанию маршрутизация directed broadcast адресов запрещена (для защиты от smurf-атак). Если на всех промежуточных роутерах между этими сетями её включить, то тогда вы опять таки получите ответ от всех работающих интерфейсов в сети 192.168.0.0/24.
И да, от того, какой вы купите свитч, дешёвый или дорогой, вышесказанное не зависит.
На пинг с адреса 192.168.0.1 на 192.168.0.255 в сети 192.168.0.0/24 ответят все работающие интерфейсы в этой сети.
Кроме того, большинство хостов считают адрес самой сети 192.168.0.0 также её броадкастовым адресом, поэтому если пропинговать 192.168.0.0, то на него тоже скорее всего ответят все работающие интерфейсы (но это не обязательно).
Если пропинговать 192.168.0.255 из какой-нибудь другой сети, например из 10.0.0.0/24 то ICMP-пакеты скорее всего отбросятся на ближайшем маршрутизаторе, т.к. по умолчанию маршрутизация directed broadcast адресов запрещена (для защиты от smurf-атак). Если на всех промежуточных роутерах между этими сетями её включить, то тогда вы опять таки получите ответ от всех работающих интерфейсов в сети 192.168.0.0/24.
И да, от того, какой вы купите свитч, дешёвый или дорогой, вышесказанное не зависит.
Прежде чем посылать IP-пакет, компьютер определяет, попадает ли адрес назначения в «свою» подсеть. Если попадает, то шлет пакет «напрямую», если же нет — отсылает его шлюзу по умолчанию (маршрутизатору).Не совсем так.
В системе может быть указано несколько шлюзов, и в списке маршрутов указано соответствие конкретных IP-подсетей конкретным шлюзам. Т.е. при отправке пакета в одни подсети будет использоваться шлюз, который определён для этих подсетей, а при отправки в другие подсети — другой шлюз, который определён для этих других подсетей.
А на шлюз по умолчанию IP-пакет будет отправляться, только если адрес назначения:
а) не входит в подсеть данного хоста (свою подсеть, определённую маской);
б) не входит в подсети, для которых в системе указан какой-то конкретный шлюз.
Потому он и называется не просто шлюз, а именно шлюз по умолчанию (default gateway), т.к. его используют только в том случае, если другие шлюзы для сетей не указаны.
Видимо, тот, кто ставит минусы, не в курсе настройки маршрутизации по подсетям…
Для примера вот типичная ситуация, когда подобная настройка используется на домашнем компьютере.
Допустим, на компьютере есть два сетевых подключения:
1) Ethernet-подключение к локальной сети;
2) Подключение к интернету, например, через DSL/GPRS/Dial-Up модем.
Чтобы при подключении модема можно было полноценно работать как с локалкой, так и с интернетом, обычно делают следующим образом:
1) В настройках подключения к локалке убирают Default gateway;
2) В качестве Default gateway используется тот, который указан в настройках модемного подключения (обычно получен автоматически);
3) Для маршрутизации в локальные IP-подсети прописывают постоянные маршруты (persistent routes) вручную:
route -p add 192.168.0.0 mask 255.255.0.0 192.168.0.1
route -p add 10.0.0.0 mask 255.0.0.0 192.168.0.1
route -p add 172.16.0.0 mask 255.240.0.0 192.168.0.1
Где 192.168.0.1 — это шлюз в вашем сегменте локальной сети, а 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12 — это IP-подсети используемые в вашей локальной сети.
После такой настройки маршрутизации пакеты, адресованные хостам внутри вашей локалки (в указанных локальных IP-подсетях), будут отправляться на указанный шлюз в локалке (192.168.0.1), согласно прописанным вручную маршрутам, а пакеты, адресованные всем прочим хостам (интернетным), будут отправляться на шлюз по умолчанию (defaul gateway) через модемное подключение в инет.
Для примера вот типичная ситуация, когда подобная настройка используется на домашнем компьютере.
Допустим, на компьютере есть два сетевых подключения:
1) Ethernet-подключение к локальной сети;
2) Подключение к интернету, например, через DSL/GPRS/Dial-Up модем.
Чтобы при подключении модема можно было полноценно работать как с локалкой, так и с интернетом, обычно делают следующим образом:
1) В настройках подключения к локалке убирают Default gateway;
2) В качестве Default gateway используется тот, который указан в настройках модемного подключения (обычно получен автоматически);
3) Для маршрутизации в локальные IP-подсети прописывают постоянные маршруты (persistent routes) вручную:
route -p add 192.168.0.0 mask 255.255.0.0 192.168.0.1
route -p add 10.0.0.0 mask 255.0.0.0 192.168.0.1
route -p add 172.16.0.0 mask 255.240.0.0 192.168.0.1
Где 192.168.0.1 — это шлюз в вашем сегменте локальной сети, а 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12 — это IP-подсети используемые в вашей локальной сети.
После такой настройки маршрутизации пакеты, адресованные хостам внутри вашей локалки (в указанных локальных IP-подсетях), будут отправляться на указанный шлюз в локалке (192.168.0.1), согласно прописанным вручную маршрутам, а пакеты, адресованные всем прочим хостам (интернетным), будут отправляться на шлюз по умолчанию (defaul gateway) через модемное подключение в инет.
Все верно, но в рамках данной статьи это не нужно. Нельзя же в одной статье рассказать всю теорию ip адресации и маршрутизации
В названии статьи «и вообще», так что почему нет. Автор говорит о масках и разбиении на подсети, но для чего это делается и к чему приводит — как-то не ясно из текста, говорит про агрегацию — опять же, для чего и как. Разговор о маске, но не сказано, что будет при использовании в одной физической сети двух логических подсетей без маршрутизации, или могут ли быть в одной сети хосты с разными масками и если да, то к каким последствиям это приведет. Получается не статья, а ознакомительная выдержка из статьи, «продолжение в следующем номере».
А потом можно и метрики в маршрутах вспомнить…
Таким образом статья начнет разрастаться до габаритов небольшой энциклопедии.
Таким образом статья начнет разрастаться до габаритов небольшой энциклопедии.
Еще можно добавить, что пакет улетит в тот шлюз, в который прописана самая «наименьшая» (точная, более специфичная) сетка, куда входит адрес назначения. Обычно применяют термин more specific.
Все верно. Только надо делить таблицу маршрутизации на транзитных устройствах (шлюзах aka маршрутизаторах) и компьютерах aka терминальных хостах.
С первым — все понятно, а со вторым — мало я видел внедрений, где наличие более одного шлюза в подсети было бы обусловлено реальной необходимостью, а не бардаком и фантазией админа.
С первым — все понятно, а со вторым — мало я видел внедрений, где наличие более одного шлюза в подсети было бы обусловлено реальной необходимостью, а не бардаком и фантазией админа.
Со вторым вариантом, это достаточно большое количество интернет провайдеров на просторах России, где используется высокоскоростная локалка на серых адреса и доступ в интернет через VPN, тут какраз и приходится городить маршрутизацию у конечного пользователя, дабы иметь доступ в локалку при подключенном VPN.
Это и есть кривой дизайн :) Хотя тут «прямой» вообще редкость в наших юдолях.
Вполне нормальный дизайн.
Мы на эту тему с вами уже общались. Пришли к одному и тому же, собственно. Второй раз не хочу )
Да? Я уже не помню, если честно. :) Anyway, в данном дизайне нет ни «дырявых» масок, ни src-specific маршрутов, а только «старые добрые» сети через интерфейс — что в общем-то и является простейшим роутингом. ;)
роутинг у клиента — это криво. не обязан клиент ничего делать сам. вы ему за деньги продали сервис в котором написано «локалка+интернет» и всё. воткнул провод в комп и всё есть, без лишних настроек. никакой статики, никакого роутинга.
… и никакого PPTP — продолжая вашу мысль.
Никто не продаёт услугу «локалка», так что это так, «прицепом» идёт к интернету.
Маршруты могут анонсироваться через DHCP.
Так что по прежнему не согласен, что это кривой дизайн.
Никто не продаёт услугу «локалка», так что это так, «прицепом» идёт к интернету.
Маршруты могут анонсироваться через DHCP.
Так что по прежнему не согласен, что это кривой дизайн.
Это нормальный дизайн, вопрос лишь в том, какие у вас туннели до абонента. Если PPPoE или 1:N VLAN — нормально, если чистый SVLAN 1:1, то так просто не работает. Если PPTP, то вообще говно, а не дизайн.
С другой стороны, ситуация потихоньку меняется. Нынешние брасы стали мощными и multi-edge будет отмирать.
Но мы, собственнно, о чем? О стоительстве сетей ШПД или о ликбезе про маски подсетей? То есть, я-то о втором, а вы — не знаю.
С другой стороны, ситуация потихоньку меняется. Нынешние брасы стали мощными и multi-edge будет отмирать.
Но мы, собственнно, о чем? О стоительстве сетей ШПД или о ликбезе про маски подсетей? То есть, я-то о втором, а вы — не знаю.
Запросто может быть более одного шлюза. Например, резервный канал с балансировкой (или без), с фаиловером и т.п. Я какие только дикие конфигурации не встречал на клиентских узлах.
Ну, да, VRRP и аналоги — наиболее правильный ответ, но в сущности это не два шлюза, а один с резервированием.
А вот балансировка таким образом — это почти наверняка полный бред.
А вот балансировка таким образом — это почти наверняка полный бред.
есть аж специальный протокол с балансировкой — GLBP. почему же бред? да и с помощью vrrp можно балансировку сделать, забавная штукенция. Когда есть серверная ферма и от неё два пути в ядро, зачем заранее занижать пропускную способность используя только один путь (активный) когда с помощью нехитрой манипуляции можно воспользоваться обоими путями и удвоить пропускную способность?
О, господи, куда катится мир. HSRP, VRRP, NSRP, JSRP, GLBP…
С точки зрения описываемого это все на одну тему: как резервировать шлюз по умолчанию.
Балансировать нагрузку (с деградацией при отказе) таким способом — воля ваша, но посмотрю я, когда вам понадобится потраблшутить такую штуку (найти определенный пакет, и дебагом поглядеть, что с ним происходит) или акцесс-листы написать. Балансировать нагрузку на шлюзы по умолчанию надо разбиением сетей на подсети. Остальное — это от безысходности, когда уже дела не очень.
С точки зрения описываемого это все на одну тему: как резервировать шлюз по умолчанию.
Балансировать нагрузку (с деградацией при отказе) таким способом — воля ваша, но посмотрю я, когда вам понадобится потраблшутить такую штуку (найти определенный пакет, и дебагом поглядеть, что с ним происходит) или акцесс-листы написать. Балансировать нагрузку на шлюзы по умолчанию надо разбиением сетей на подсети. Остальное — это от безысходности, когда уже дела не очень.
IRDP ещё забыли :-D
Тот же самый citrix требует, чтоб виртуальные адреса клиентов были в одной подсети с citrix-хостом, так что разбиение — далеко не всегда вариант.
Тот же самый citrix требует, чтоб виртуальные адреса клиентов были в одной подсети с citrix-хостом, так что разбиение — далеко не всегда вариант.
1. Да небось еще десяток можно насчитать.
2. Вы либо чего-то путаете, либо цитрикс ничего не слыхал про IP-маршрутизацию. В последнем я, если честно, сомневаюсь, при всем уважении к вам.
2. Вы либо чего-то путаете, либо цитрикс ничего не слыхал про IP-маршрутизацию. В последнем я, если честно, сомневаюсь, при всем уважении к вам.
я имею в виду вот что: когда приложение запускается на сервере приложений citix от имени какого-то удаленного пользователя и это приложение дальше использует сетевые ресурсы (ну допустим пользователь с тонким клиентом запустил веб-браузер на сервере и лезет из браузера куда-то на веб-сервер), то по-умолчанию src-адрес этого подключения будет адресом сервера приложений, соотвественно все удаленные пользователи будут иметь один и тот же src-адрес всегда. Иногда с этим возникают проблемы, когда какие-то приложения дифференцируют пользователей по ip-адресам, а иногда возникают проблемы с фаерволлами и ip-sec-ом. У ситрикса есть опция, при включении которой он каждому пользователю навешивает виртуальный адрес из пула адресов закрепленных за сервером и все приложения запускаемые пользователем ориджинируется уже с этого виртуального адреса. Так вот, пул виртуальных адресов должен быть в одной подсети с адресом сервера приложений ситрикса. И никакой магии.
А. Ну это все равно, что куча пользователей в одной подсети, в сущности. Уж как они там получают доступ к своим рабочим местам: руками и глазами, удаленно через цитрикс, телепатически или методом бифуркации кармических состояний — дело сто пятьдесят третье.
Но непонятно, какое это имеет отношение к балансировке по двум дефолт-гейтвеям :)
Но непонятно, какое это имеет отношение к балансировке по двум дефолт-гейтвеям :)
нет, это конкретный глюк ситрикса, потому как если бы разработчики ситрикса имели понятие о маршрутизации, то виртуальный пул можно было бы и отвязать от сети на интерфейсе (vmware, например, прекрасно умеет делать любые адреса для виртуальных машин, независимо от адреса физического хоста).
а отношение простое — когда есть сервер ситрикса с чуть менее чем дохренища пользователей, то от него и к нему генерится чуть менее чем дохренища трафика и балансировать его, в случае с ситриксом, не получится вашим методом по причине указанной выше. подобные проблемы можно найти в очень многих продуктах, особенно связанных с кластеризацией, когда ноды кластера обязаны быть в одной подсети. Checkpoint NGX ещё, например.
а отношение простое — когда есть сервер ситрикса с чуть менее чем дохренища пользователей, то от него и к нему генерится чуть менее чем дохренища трафика и балансировать его, в случае с ситриксом, не получится вашим методом по причине указанной выше. подобные проблемы можно найти в очень многих продуктах, особенно связанных с кластеризацией, когда ноды кластера обязаны быть в одной подсети. Checkpoint NGX ещё, например.
Аа-а.
Насколько я знаю, привязка пулов витруальных адресов к интерфейсным подсетям — это сознательная позиция в некоторых продуктах. Иначе нужно писать какой-то роутинг или арп-прокси. Одни заказчики начнут ныть, что это слишком сложно, другие скажут, мол, подавай нам OSPF с BGP. Это все толкает продукт в другую нишу рынка, более эдвансную, что не всегда оправдано с коммерческой точки зрения. Но я согласен, что технически так лучше.
Но. Что-то я сомневаюсь, что это нормально, если один дефолт-гейтвей не способен пережевать нагрузку, которую может дать один цитрикс-сервер.
Насколько я знаю, привязка пулов витруальных адресов к интерфейсным подсетям — это сознательная позиция в некоторых продуктах. Иначе нужно писать какой-то роутинг или арп-прокси. Одни заказчики начнут ныть, что это слишком сложно, другие скажут, мол, подавай нам OSPF с BGP. Это все толкает продукт в другую нишу рынка, более эдвансную, что не всегда оправдано с коммерческой точки зрения. Но я согласен, что технически так лучше.
Но. Что-то я сомневаюсь, что это нормально, если один дефолт-гейтвей не способен пережевать нагрузку, которую может дать один цитрикс-сервер.
Кстати, не знаю за цитрикс, но вообще стандартный обход этого ограничения (собственно, как разработчики и хотели) — создание loopback-интерфейса, на который вешается хоть 10/8, и из нее нарезаются какие хошь пулы. Включение OSPF на этом loopback-интерфейсе также не возбраняется.
городить маршрутизацию между сетевым железом и серверами под Win? :) я уж лучше как-то с vrrp/glbp поиграюсь, зато хоть уверен буду в этом.
Чем длиннее маска, тем меньше в ней хостов.Наоборот, не?
про ipv6 будет такая статья? А то этот ipv6 у меня в голове не укладывается(((
Самому пока лень. А если по-английски читаете, то вот:
www.nanog.org/meetings/nanog46/presentations/Sunday/RAS_Practical_ipv6_61309_N46.pdf
www.nanog.org/meetings/nanog46/presentations/Sunday/RAS_Practical_ipv6_61309_N46.pdf
То есть, это, конечно, не «такая статья» ни полраза (ликбез, но другого уровня). Однако, судя по тому, что вы пишете, вам будет в самый раз )
Его (обычно) нельзя использоватьХотелось бы по-подробнее про "(обычно)". Можно, нельзя, или где конкретно можно, а где нельзя? Используется ли адрес сети (именно как адрес сети, а не узла) вообще хоть где-нить для чего-нить, я имею в виду — в коде? Или только для документирования сети и общения админов? И что происходит с броадкастами — они таки работают, или нет? Точнее, я знаю, что они иногда работают, а иногда нет, но интересно — они должны работать, или не должны?
Про необычный вариант для адреса сети. К примеру у вас есть некий VPN сервер, куда подключаются клиенты, и им вполне можно выдать на ppp интерфейсы и 192.168.8.0 и даже 192.168.15.255, и это все будет работать.
А на предыдущем роутере, чтобы достучаться до этих клиентов вы так и будете прописывать route add -net 192.168.8.0/21 gw <vpn_serv_ip>. В этом случае все адреса из подсети равноправные.
А на предыдущем роутере, чтобы достучаться до этих клиентов вы так и будете прописывать route add -net 192.168.8.0/21 gw <vpn_serv_ip>. В этом случае все адреса из подсети равноправные.
Вообще, в статье про это есть. См. про маски /31 на p2p-линках.
И еще вот, в соседней ветке: habrahabr.ru/blogs/sysadm/129664/#comment_4311683
И еще вот, в соседней ветке: habrahabr.ru/blogs/sysadm/129664/#comment_4311683
Первый курс Cisco Intro для сертификации CCNA очень хорош именно объяснением всей этой математики без привязки к их оборудованию.
Ага, и этим хороши еще сотни статей, на которые попадаешь через три секунды поиска в гугле.
Сто лет на хабр не заходил, но тут явно ничего не меняется. Сначала один напишет, что Земля круглая, а потом его начинают дружно обвинять в том, что написал муть, скопипастенную из википедии, и вываливают почти то же самое, только другими словами.
Salium, ничего личного, и Ваше негодование по поводу «тех статей» понятно, но эта тогда зачем? Если она претендует на универсальный справочник, который каждый, у кого под рукой нет гугла, а есть лишь хабр, должен добавить в избранное, чтобы в случае чего быстренько заглянуть и посчитать нужную маску — то не хватает достаточно многих вещей, тех же основ перевода dec<>bin или знакомой каждому админу таблички префиксов с числом хостов.
Если пост претендует на что-то другое (срывание покровов, раскрытие тайн вселенной, уничижение неграмотных авторов унылых постов на эту же тему), то в нем вообще ничего уникального.
Сто лет на хабр не заходил, но тут явно ничего не меняется. Сначала один напишет, что Земля круглая, а потом его начинают дружно обвинять в том, что написал муть, скопипастенную из википедии, и вываливают почти то же самое, только другими словами.
Salium, ничего личного, и Ваше негодование по поводу «тех статей» понятно, но эта тогда зачем? Если она претендует на универсальный справочник, который каждый, у кого под рукой нет гугла, а есть лишь хабр, должен добавить в избранное, чтобы в случае чего быстренько заглянуть и посчитать нужную маску — то не хватает достаточно многих вещей, тех же основ перевода dec<>bin или знакомой каждому админу таблички префиксов с числом хостов.
Если пост претендует на что-то другое (срывание покровов, раскрытие тайн вселенной, уничижение неграмотных авторов унылых постов на эту же тему), то в нем вообще ничего уникального.
Нет никакого негодования. Каждый делает, что хочет.
Есть масса вещей в жизни, про которые все давно известно. Тем не менее про них пишут. Например школьные учебники по естественным дисциплинам. Или буквари. Не поверите, иногда получается хуже, а иной раз лучше, чем все предыдущее. Бывет, что и гениально (не претендую :)
Есть масса вещей в жизни, про которые все давно известно. Тем не менее про них пишут. Например школьные учебники по естественным дисциплинам. Или буквари. Не поверите, иногда получается хуже, а иной раз лучше, чем все предыдущее. Бывет, что и гениально (не претендую :)
одно могу сказать, из всех упомянутых сотен нефтистатей, это первая в которой рассказали про возможность использовать подсети /31. у меня это первый любимый вопрос на собеседовании на тему широты кругозора. 98% интервьируемых понятия не имеют о возможности использования /31 и о RFC 3021
В своё время на ВМК МГУ в курсе системного администрирования это было, кстати :-)
Кого ж вы собеседуете?..-) Нет, серьезно, любой, кто хотя бы удосужился что-то почитать, прежде чем конфигурить, это знает. На моей прежней и текущей работе все, кто циску трогает, в курсе. И даже на инглиш-wiki в статье по маскам это есть.
И возвращаясь к моему брюзжанию в прошлом комменте: блог «Системное администрирование». Вашу ж мать, давайте сюда еще про то, как обжимать патчкорды, писать будем.
Чуть ниже верная точка зрения: «Мне (ни разу не админу) было интересно почитать». Вот и пусть это идет в другой блог («разное», «это интересно», «а вот мне вчера приснилось»).
Я за свободу самовыражения, но если уж тут модерируют и даже (ой, мамочки!) иногда банят, то пусть и фильтруют хоть как-то, если уж сами члены сообщества не хотят. Сетовали, что весь хабр превращается в не-ИТ сообщество, а тут уже и тематические блоги скатываются до уровня ликбеза.
P.S. А может, это я злой, потому что в отпуск хочу, а не пускают-)
И возвращаясь к моему брюзжанию в прошлом комменте: блог «Системное администрирование». Вашу ж мать, давайте сюда еще про то, как обжимать патчкорды, писать будем.
Чуть ниже верная точка зрения: «Мне (ни разу не админу) было интересно почитать». Вот и пусть это идет в другой блог («разное», «это интересно», «а вот мне вчера приснилось»).
Я за свободу самовыражения, но если уж тут модерируют и даже (ой, мамочки!) иногда банят, то пусть и фильтруют хоть как-то, если уж сами члены сообщества не хотят. Сетовали, что весь хабр превращается в не-ИТ сообщество, а тут уже и тематические блоги скатываются до уровня ликбеза.
P.S. А может, это я злой, потому что в отпуск хочу, а не пускают-)
Мне (ни разу не админу) было интересно прочитать.
Узнал, зачем нужны маски.
Узнал, зачем нужны маски.
192.168.11.10/21 :::: 11000000.10101000.00001011.00001010
Или в IP-адресе надо 10 на 11 сменить или в двоичной система 1011 на 1010.
Или в IP-адресе надо 10 на 11 сменить или в двоичной система 1011 на 1010.
Насчёт /32 — неправда. /32 выдаётся p2p линкам в VPN, например. И совсем не в «индивидуальном» порядке, просто там unnumbered интерфейс.
внутри подсети 192.168.8.0/24
Вроде речь сначала шла про /21 сеть.
Вроде речь сначала шла про /21 сеть.
как я считаю сколько IP в подсети:
— маска /26 = 32(бита макс. значение) — 26 = 6; 2^6= 64 IP
— маска 255.255.224.0 = 256(макс. значение) — 224 = 32 (подсети /24) = 32 *256 = 8192 IP
ps: there is no place like 7F000001
— маска /26 = 32(бита макс. значение) — 26 = 6; 2^6= 64 IP
— маска 255.255.224.0 = 256(макс. значение) — 224 = 32 (подсети /24) = 32 *256 = 8192 IP
ps: there is no place like 7F000001
«Сеть класса С», это уже по сути дела устоявшийся термин, который имеет к изначальным классам сети опосредованное отношение и совпадает только по размерности маски. Т.е. фразы типа «круто, у них целых 5 сетей класса С» вполне общеупотребимые.
Если уж так дотошно подходить к терминологии, то модель OSI имеет к tcp/ip очень опосредованное отношение. Уровни tcp/ip по сути дела «натянули» на 7-уровневую модель, а точнее говоря притянули за уши, т.к. уровни у них совпадают только номинально по названиям. Меня вот тоже корежит когда ее упоминают, но ничего — терплю. Также и с классами. Их названия по сути дела сейчас используются для указания размерности масок.
Если уж так дотошно подходить к терминологии, то модель OSI имеет к tcp/ip очень опосредованное отношение. Уровни tcp/ip по сути дела «натянули» на 7-уровневую модель, а точнее говоря притянули за уши, т.к. уровни у них совпадают только номинально по названиям. Меня вот тоже корежит когда ее упоминают, но ничего — терплю. Также и с классами. Их названия по сути дела сейчас используются для указания размерности масок.
Ну и плюс попробуйте на любом (ну почти любом) маршрутизаторе задать адрес без маски и поймете, что они живее всех живых :)
Просто изначальная идея — выдавать организациям сети классами в зависимости от размера организации, оказалась утопичной — слишком много контор в мире :) А в остальном классы живут :)
Просто изначальная идея — выдавать организациям сети классами в зависимости от размера организации, оказалась утопичной — слишком много контор в мире :) А в остальном классы живут :)
Из того, что иной софт по старинке назначает дефолтовую длину маски исходя из класса адреса, не следует, что классы живы. Можно и другое правило избрать, например назначать всем линкам по умолчанию /24 или /30. Толку будет даже чуть больше.
А JUNOS вот например появился, когда уже никаких классов не было, не знает про них ничего, по умолчанию в описываемой ситуации назначает /32 и прекрасно себя чувствует.
А JUNOS вот например появился, когда уже никаких классов не было, не знает про них ничего, по умолчанию в описываемой ситуации назначает /32 и прекрасно себя чувствует.
ХЗ. Встречал несколько раз, когда сетки типа 10/8 и т.п. роутились в удаленный филиал без указания масок, т.к. жили там целиком. Собственно зачем указывать, если он сам допишет? Если современные железки это делать не умеют, то очень зря. Когда циска выпилит это, то откажемся от такой практики :)
Мне кажется это какой-то дурной тон на это надеяться, обычно стараются указывать все как можно более точно, чтобы не зависеть от того, какие настройки по умолчанию решит сделать производитель завтра.
Примерно такой же, как и рекомендуемый в статье — 192.168/16. Встречались мне железки, которые такое не переваривали. Писать везде полную запись, даже если железка точно поддерживает короткую? А смысл. Если железка нормально все переваривает, и админ точно знает ее возможности, то почему бы и нет? Все равно при смене железки надо будет весь конфиг проверять на работоспособность.
Ну этот способ в статье ни как рекомендуемый, а просто как возможный.
В принципе то согласен, что если железка одна и ты ее полностью знаешь, то можно и всякие хаки использовать такие.
Но когда железок туева хуча и у каждой свои особенности, причем разные от прошивки к прошивке (привет длинку))), тут уже, как мне кажется, не до использования таких фич.
Вон у яндекса не так давно внезапно оказалась включена редистрибуция бгп подефолту )))
В принципе то согласен, что если железка одна и ты ее полностью знаешь, то можно и всякие хаки использовать такие.
Но когда железок туева хуча и у каждой свои особенности, причем разные от прошивки к прошивке (привет длинку))), тут уже, как мне кажется, не до использования таких фич.
Вон у яндекса не так давно внезапно оказалась включена редистрибуция бгп подефолту )))
1. Ну, воля ваша. Можно и Таллин с двумя нэ на конце писать :)
2. Я не согласен. Но это хливор. Не хочу продолжать. Многие уважаемые мною эксперты считают похожим образом. Я иногда с ними спорю, бывает даже, что переубеждаю. Общий хинт: надо делить инкапсуляцию заголовков и функциональное назначение протоколов и технологий. ATM вот не поделила, и сдохла.
2. Я не согласен. Но это хливор. Не хочу продолжать. Многие уважаемые мною эксперты считают похожим образом. Я иногда с ними спорю, бывает даже, что переубеждаю. Общий хинт: надо делить инкапсуляцию заголовков и функциональное назначение протоколов и технологий. ATM вот не поделила, и сдохла.
Маска подсети — это тоже 32-бита. Но в отличии от IP-адреса, нули и единицы в ней не могут чередоваться. Всегда сначала идет сколько-то единиц, потом сколько-то нулей. Не может быть маски
120.22.123.12=01111000.00010110.01111011.00001100.
www.tcpipguide.com/free/t_IPSubnetMasksNotationandSubnetCalculations-4.htm
начиная с "RFC 950 actually specified..."
120.22.123.12=01111000.00010110.01111011.00001100.
www.tcpipguide.com/free/t_IPSubnetMasksNotationandSubnetCalculations-4.htm
начиная с "RFC 950 actually specified..."
в самом RFC 950 это видимо описывается абзацем:
Since the bits that identify the subnet are specified by a bitmask, they need not be adjacent in the address. However, we recommend that the subnet bits be contiguous and located as the most significant bits of the local address.
Since the bits that identify the subnet are specified by a bitmask, they need not be adjacent in the address. However, we recommend that the subnet bits be contiguous and located as the most significant bits of the local address.
Спасибо, не знал. Хотя… ну вы понимаете :)
А если честно, недавно на собеседовании одного бедолагу мучил, а когда он спросил «почему, собственно, маска обязана быть бездырочной» — задумался.
Бедолагу взяли — хэппиэнд ;)
UFO just landed and posted this here
Спасибо большое!
Вот вас вверху благодарят от всего сердца, а комментарий заминусован. Странно, видимо это люди, кто в теме глубоко. Зря вы так, господа!
Вот я технарь, но с IP-сетями никогда плотно не сталкивался, а времени нет прочитать всё, что интересно. А в такой сжатой форме — то что доктор прописал!
Вот вас вверху благодарят от всего сердца, а комментарий заминусован. Странно, видимо это люди, кто в теме глубоко. Зря вы так, господа!
Вот я технарь, но с IP-сетями никогда плотно не сталкивался, а времени нет прочитать всё, что интересно. А в такой сжатой форме — то что доктор прописал!
>И последнее. Пресловутые классы адресов. Дорогие товарищи, забудьте это слово вообще! Совсем. Вот уже скоро 20 лет (!), как нет никаких классов.
Ага, ну конечно. No auto summary и ip classless в цисках яркий тому пример. + Стоит понимать, какой диапазон подразумевается, когда «матерые специалисты» говорят не «Блок 224.0.0.0/4», а сеть класса D.
Ага, ну конечно. No auto summary и ip classless в цисках яркий тому пример. + Стоит понимать, какой диапазон подразумевается, когда «матерые специалисты» говорят не «Блок 224.0.0.0/4», а сеть класса D.
Ну, ладно, ладно. Вы круты, ОК. Хотите плюсану? :)
habrahabr.ru/blogs/sysadm/129664/#comment_4311725
Только 224/4 — это в сущности просто договоренность, какие адреса использовать для мультикаста. Родилась она из классов, но, собственно, на этом и все. С таким же успехом могло быть 10/8. То есть никакой технической разницы нету. А все-таки в классах в их изначальном виде разница была.
А в цисках приведенные команды — это именно что способ забыть про атавизм. Не могут они выкласть на обратную совместимость. А Juniper вот появился, когда этого всего уже не были, и смог выкласть сразу. И никто не умер.
habrahabr.ru/blogs/sysadm/129664/#comment_4311725
Только 224/4 — это в сущности просто договоренность, какие адреса использовать для мультикаста. Родилась она из классов, но, собственно, на этом и все. С таким же успехом могло быть 10/8. То есть никакой технической разницы нету. А все-таки в классах в их изначальном виде разница была.
А в цисках приведенные команды — это именно что способ забыть про атавизм. Не могут они выкласть на обратную совместимость. А Juniper вот появился, когда этого всего уже не были, и смог выкласть сразу. И никто не умер.
Я уже который раз поражаюсь — я указываю на абсурдность высказывания, а кто-то на меня обижается.
Ну вот как можно забыть про классы, когда один из крупнейших поставщиков оборудования использует их в своем дефолтном конфиге(прошу заметить — я не говорю, что это ппц как удобно каждый раз изменять это в конфиге, но пока в конфигах дефолтом стоит auto summary итд наверное стоит помнить об этом).
Просто не нужно писать так категорично, ведь вашу статью читают люди. А потом эти люди иногда приходят на собеседование и могут вынести всем мозг такими заявлениями.
Ну вот как можно забыть про классы, когда один из крупнейших поставщиков оборудования использует их в своем дефолтном конфиге(прошу заметить — я не говорю, что это ппц как удобно каждый раз изменять это в конфиге, но пока в конфигах дефолтом стоит auto summary итд наверное стоит помнить об этом).
Просто не нужно писать так категорично, ведь вашу статью читают люди. А потом эти люди иногда приходят на собеседование и могут вынести всем мозг такими заявлениями.
Ой, ладно вам. «Обижается» — это вообще не про меня.
Люди, которые имеют дело с настройкой маршрутизаторов (причем в их случаях не все равно, что делают указанные команды) станут читать мой ликбез и воспринимать его как единственное руководство к действию? Если так, то им уже и профессор Преображенский не поможет.
В крайнем случае таким людям достаточно запомнить, что что указанные команды надо просто всегда вводить, «чтобы не было какой-то допотопной хрени», и этого будет вполне достаточно )
Люди, которые имеют дело с настройкой маршрутизаторов (причем в их случаях не все равно, что делают указанные команды) станут читать мой ликбез и воспринимать его как единственное руководство к действию? Если так, то им уже и профессор Преображенский не поможет.
В крайнем случае таким людям достаточно запомнить, что что указанные команды надо просто всегда вводить, «чтобы не было какой-то допотопной хрени», и этого будет вполне достаточно )
Один из поставщиков это циска? Auto-summary для BGP и, прости господи, EIGRP, отключено начиная с 12.2(8)T. Произошло это, конечно, не так чтобы очень давно, но всё-таки произошло. Фича осталась включённой только для RIPv2, но там это совершенно непринципиально, в энтерпрайзе такие вопросы не встают.
Я один раз напоролся на эту гадость, кстати. Была сеточка, построенная на каком-то старье, даже не помню как оно называется. Софт там стоял из 11 семейства. Я же ставил 7206 с 12.4. Сеточку надо было смигрировать на BGP. Адресация у них была в сетке 10/8, каждая подсеть представляла собой /24. В какой-то момент дефолтное автосаммари сыграло со мной злую шутку:) Слава богу, такие вещи уже не надо держать в голове.
Я один раз напоролся на эту гадость, кстати. Была сеточка, построенная на каком-то старье, даже не помню как оно называется. Софт там стоял из 11 семейства. Я же ставил 7206 с 12.4. Сеточку надо было смигрировать на BGP. Адресация у них была в сетке 10/8, каждая подсеть представляла собой /24. В какой-то момент дефолтное автосаммари сыграло со мной злую шутку:) Слава богу, такие вещи уже не надо держать в голове.
Значит, EIGRP — «прости господи», а RIPv2 — «в энтерпрайзе». От, понимашь, нелюбовь к proprietary до чего доводит ;)
Да сейчас в энтерпрайзе чаще OSPF встречается, нежели RIP. А к EIGRP я тёплых чувств никогда не испытывал, ибо интероп рано или поздно неизбежен, любое proprietary считаю обречённым:)
Ну вы поняли. Это было (шутя) не про OSPF vs RIPv2 и не про EIGRP vs OSPF, а про RIPv2 vs EIGRP.
Кстати, если серьезно, когда последний раз RIP в жизни видели? Ну так, чтоб прям сеть. Не в смысле там чего, а любопытно, вдруг где оно живо в промышленных количествах.
Я — года два назад, но несерьезно: пара офисов, связанных IPSec'ом, поверх которого оно. Админу заказчика делать было нечего. А так вот прям чтоб сеть… аж в 2003 году был заказчик, которой всех забодал вопросами про каждую строчку в конфиге, и было принято политическое решение, что объяснения слова «ария» мы не переживем. Пяток рутеров с десятком сетей был у него. Причем даже не v2.
Кстати, если серьезно, когда последний раз RIP в жизни видели? Ну так, чтоб прям сеть. Не в смысле там чего, а любопытно, вдруг где оно живо в промышленных количествах.
Я — года два назад, но несерьезно: пара офисов, связанных IPSec'ом, поверх которого оно. Админу заказчика делать было нечего. А так вот прям чтоб сеть… аж в 2003 году был заказчик, которой всех забодал вопросами про каждую строчку в конфиге, и было принято политическое решение, что объяснения слова «ария» мы не переживем. Пяток рутеров с десятком сетей был у него. Причем даже не v2.
Понял, понял:)
В промышленных не видел, наверное, очень давно. В несерьёзных — два раза. Первый — один в один как и у вас — элементарный роутинг между офисами. Второй — это был костыль. Делали один проект, и уже в ходе проекта возникло требование подцепить коммутатор в OSPF-домен. Коммутатором оказался кастомерский 3750-E с базовой лицензией, которая не умеет OSPF. Пришлось делать RIP и заморачиваться с редистрибуцией префиксов из OSPF в это безобразие. Потом заказчик купил правильную лицензию, и костыль убрали.
EIGRP последний раз видел в описанном мной кейсе с автосаммари BGP. Суть того проекта заключалась в миграции сети с EIGRP на OSPF+BGP. Пожалуй, это был первый и последний раз.
В промышленных не видел, наверное, очень давно. В несерьёзных — два раза. Первый — один в один как и у вас — элементарный роутинг между офисами. Второй — это был костыль. Делали один проект, и уже в ходе проекта возникло требование подцепить коммутатор в OSPF-домен. Коммутатором оказался кастомерский 3750-E с базовой лицензией, которая не умеет OSPF. Пришлось делать RIP и заморачиваться с редистрибуцией префиксов из OSPF в это безобразие. Потом заказчик купил правильную лицензию, и костыль убрали.
EIGRP последний раз видел в описанном мной кейсе с автосаммари BGP. Суть того проекта заключалась в миграции сети с EIGRP на OSPF+BGP. Пожалуй, это был первый и последний раз.
Про лицензии на коммутаторах-то я и забыл. Вендоры, конечно говнюки в этом смысле. Уж бы совсем ничего не делали лучше, чем бесплатно RIP. Недавно тут консультировал заказчика, который таки купил без малого вагон EX2200, собираясь обставить ими чуть ни полстраны и построить на них супир-пупир провайдырскую сеть. При помощи plain IP с RIP. Консультирование свелось к констатации того, что сам делай что хочешь, но ни внедрять, ни поддерживать мы это не будем.
А с EIGRP — знаю один весьма крупный энтерпрайз, где оно прекрасно себя чувствует до сих пор. Причем админы там на редкость крутые перцы (в самом хорошем смысле). Внедряли им таки Juniper'овскую коробку, но немного сбоку-припеку, так что EIGRP<->OSPF получилось, в целом, даже красиво, как по учебнику.
А с EIGRP — знаю один весьма крупный энтерпрайз, где оно прекрасно себя чувствует до сих пор. Причем админы там на редкость крутые перцы (в самом хорошем смысле). Внедряли им таки Juniper'овскую коробку, но немного сбоку-припеку, так что EIGRP<->OSPF получилось, в целом, даже красиво, как по учебнику.
Суперпупер SP-сетка на RIP, да на EX2200 это действительно круто, да. Если мне память не изменяет, то именно 2200 является не джуниперовской разработкой, а каким-то унылым OEM, в отличие от старших моделей, которые весьма адекватны.
По поводу EIGRP, дабы закрыть эту тему — любое пропраитори, что очевидно, закрывает полностью или же очень сильно ограничивает возможность развития сети на оборудовании иных вендоров. Обоснованность применения в том или ином случае любой proprietary-фичи должна быть очень серьёзной. В противном случае — создание искуственных ограничений, которые на пользу делу не идут. Мультивендорность необходимо держать в голове, т.к. это позволит избежать массы проблем в будущем. Вот у нас сейчас тут есть один вариантик — небольшой оператор, который во все поля делает псевдопровода по Компелле, а тут оказалось, что сеть будет расширяться уже на циске. Итог — ломать всё и вся, а ведь можно было сразу делать Мартини и проблем не знать. В общем это мы не в ту сторону уже пошли.
По поводу EIGRP, дабы закрыть эту тему — любое пропраитори, что очевидно, закрывает полностью или же очень сильно ограничивает возможность развития сети на оборудовании иных вендоров. Обоснованность применения в том или ином случае любой proprietary-фичи должна быть очень серьёзной. В противном случае — создание искуственных ограничений, которые на пользу делу не идут. Мультивендорность необходимо держать в голове, т.к. это позволит избежать массы проблем в будущем. Вот у нас сейчас тут есть один вариантик — небольшой оператор, который во все поля делает псевдопровода по Компелле, а тут оказалось, что сеть будет расширяться уже на циске. Итог — ломать всё и вся, а ведь можно было сразу делать Мартини и проблем не знать. В общем это мы не в ту сторону уже пошли.
Не, не, EX2200 родные. Это 2500 ОЕМ (24x10GE). Я даже, если напрягусь, вспомню название тех китайцев, которые это под своим лейблом делают. На нем по-моему L3 ваще нету, но могу ошибаться тут.
А 2200 — это 24/28 медных GE + 4 SFP, типа, аплинка. Десяток нет. Data plane под L3 (ну, понятно, plain IP) там вполне нормальный, wirespeed, VR'ы, а вот из протоколов пока только RIP. OSPF когда-то сделают, но за лицензию.
А 2200 — это 24/28 медных GE + 4 SFP, типа, аплинка. Десяток нет. Data plane под L3 (ну, понятно, plain IP) там вполне нормальный, wirespeed, VR'ы, а вот из протоколов пока только RIP. OSPF когда-то сделают, но за лицензию.
Отдельный коментом.
1. Ну, в контексте EIGRP — понятно, чего тут обсуждать-то. Но Тут есть всеми поддерживаемы энтерпрайзный стандарт де-факто. Я-то написал, что вот, мол бвыает и так.
2. А вот с компеллой не все так гладко. Все же, если б это совсем одно и то же было, то компелла б никому не нужна была :) Если там реальный провижнинг VPN'ов, то, ага, пускай попробуют без BGP, посмотрю я на них :) А если оно ненапряжно, то наверное да, надо было подумать о мультивендорности. Кстати, хуавей например компеллу умеет )
1. Ну, в контексте EIGRP — понятно, чего тут обсуждать-то. Но Тут есть всеми поддерживаемы энтерпрайзный стандарт де-факто. Я-то написал, что вот, мол бвыает и так.
2. А вот с компеллой не все так гладко. Все же, если б это совсем одно и то же было, то компелла б никому не нужна была :) Если там реальный провижнинг VPN'ов, то, ага, пускай попробуют без BGP, посмотрю я на них :) А если оно ненапряжно, то наверное да, надо было подумать о мультивендорности. Кстати, хуавей например компеллу умеет )
Да много кто умеет — алколюсент тоже. Но, пацаны из циски говорят, что оно-таки скоро и у них заработает, посмотрим.
С другой стороны — если бы всё было так просто, нам нечего было бы кушать;)
С другой стороны — если бы всё было так просто, нам нечего было бы кушать;)
>Но, пацаны из циски говорят, что оно-таки скоро и у них заработает, посмотрим.
Та вы чо? Неужели.
Та вы чо? Неужели.
Промелькнула такая новость пару месяцев назад. В упор не помню для какой платформы, надо у коллег уточнить.
Вспомнил тут, что читал когда-то про LDP signaling with BGP autodiscovery для Мартини.
В сущности та же схема внешнего автодискавери, что для VPLS. И то и другое вроде описано в недавно принятом rfc6074. Но только для VPLS оно как-то на слуху, и даже встречается в жизни (еще когда было в драфте), то для псевдопроводов я никогда не интересовался, поддерживается ли где, и как там с интероперабельностью.
Судя по свежести стандарта и составу авторов… — как бы это не было тем, что вы приняли за обещанную поддержку Компеллы.
В сущности та же схема внешнего автодискавери, что для VPLS. И то и другое вроде описано в недавно принятом rfc6074. Но только для VPLS оно как-то на слуху, и даже встречается в жизни (еще когда было в драфте), то для псевдопроводов я никогда не интересовался, поддерживается ли где, и как там с интероперабельностью.
Судя по свежести стандарта и составу авторов… — как бы это не было тем, что вы приняли за обещанную поддержку Компеллы.
Я вот, кстати, не помню, внутренний CCC на Juniper между мартини и компеллой сделать можно? На худой конец есть старый добрый hairpin.
не хотите у нас в университете лекции по сетям ЭВМ читать?
У нас препод по курсу «Компьютерные сети», с полной уверенностью доказывал что в IPv6 6 байт, то есть 48 бит, по анологии с Ipv4 где 4 байта.
«Четыре октета (то же, что байта, но если вы хотите блеснуть, то говорите «октет» — сразу сойдете за своего)»
Вот именно потому, что октет и байт — две разные вещи, говорят «октет».
Вот именно потому, что октет и байт — две разные вещи, говорят «октет».
Понравилась цитата «Этот адрес называется направленным бродкастом (широковещательным) для данной сети. Смысл его по нынешним временам весьма невелик: когда-то было поверье, что все хосты в подсети должны на него откликаться, но это было давно и неправда.»
Прям в точку)))
Прям в точку)))
Давно хотел понять эту вещь, но не было времени, а тут как раз в тему. Очень доступно и понятно написал. Спасибо!
Боже, не дай мне стать админом. Не хочу я среди ночи, бухим, знать из скольки бит состоит IP-адрес IPv6
«Любой уважающий себя администратор обязан уметь переводить IP-адреса из десятичной формы в двоичную и обратно в уме или на бумажке,»
Вот никак не пойму зачем это знать?
Вот никак не пойму зачем это знать?
Чтобы рассчитывать маски подсети и переводить из одного вида в другой (нормальная, wildcard, по количеству бит).
На самом деле реально это нужно разве что только на тестах и собеседованиях ;) Во всех остальных случаях ipcalc надёжнее и быстрее.
Он не всегда есть под рукой, ну и для быстрого понимания области действия ACL тоже лишним не будет.
Когда его нет под рукой, смысл подсчёта теряется, ибо это значит что у вас нет под рукой основного рабочего инструмента — компьютера. ;)
«Быстрое понимание области действия ACL», особенно на «нестандартных» конфигурациях (т.е. отличных от часто используемых и потому хорошо запоминаемых /24) чревато быстрыми же ошибками при подсчёте, что чревато совсем уж плохими последствиями.
Не говоря уж о том, что чем больше IPv6 будет проникать в нашу жизнь, тем больше, в силу очевидных причин, устный расчёт будет терять смысл.
«Быстрое понимание области действия ACL», особенно на «нестандартных» конфигурациях (т.е. отличных от часто используемых и потому хорошо запоминаемых /24) чревато быстрыми же ошибками при подсчёте, что чревато совсем уж плохими последствиями.
Не говоря уж о том, что чем больше IPv6 будет проникать в нашу жизнь, тем больше, в силу очевидных причин, устный расчёт будет терять смысл.
Компьютеры бывают разные. В т. ч. чужие, в т. ч. без интернета.
Но дело даже не в этом. См. habrahabr.ru/blogs/sysadm/129664/#comment_4313055
Но дело даже не в этом. См. habrahabr.ru/blogs/sysadm/129664/#comment_4313055
Приходит в TAC обращение с симтомом, типа, я с машины 10.0.0.63 не пингую дефолт гейтвей. А на интерфейсе гейтвея стоит адрес 10.0.0.1/26. Если инженер поддержки ничего не заподозрит, то и не спасет его никакой ipcalc. Вместо 20 секунд потратит несколько дней, пока случайно не придет в голову вбить адерса в калькулятор.
Вы с такой ситуацией когда-нибудь сталкивались? Я не встречал, честно говоря, ситуаций, в которых можно было бы забить gateway вне сети интерфейса — ни винда, ни линукс, ни фряха такого сделать просто не дадут.
:) Вот за этим нужно уметь чуять цифры жопой. В примере оба адреса из одной подсети.
Я не стал заморачиваться и ошибся, да :) Бродкаст адрес на интерфейсе сомневаюсь, что сможет поставить, кстати.
root@linux-host:~# ifconfig eth0 10.0.0.63 netmask 255.255.255.192
root@linux-host:~# route add default gw 10.0.0.1
root@linux-host:~# ifconfig eth0 | grep «inet addr»
inet addr:10.0.0.63 Bcast:10.0.0.63 Mask:255.255.255.192
root@linux-host:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.0.0.0 0.0.0.0 255.255.255.192 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 10.0.0.1 0.0.0.0 UG 0 0 0 eth0
root@linux-host:~#
root@linux-host:~# route add default gw 10.0.0.1
root@linux-host:~# ifconfig eth0 | grep «inet addr»
inet addr:10.0.0.63 Bcast:10.0.0.63 Mask:255.255.255.192
root@linux-host:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.0.0.0 0.0.0.0 255.255.255.192 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 10.0.0.1 0.0.0.0 UG 0 0 0 eth0
root@linux-host:~#
Упс. Так понятнее будет
root@linux-host:~# ifconfig eth0 10.0.0.63 netmask 255.255.255.192
root@linux-host:~# route add default gw 10.0.0.1
root@linux-host:~# ifconfig | grep "inet addr"
inet addr:10.0.0.63 Bcast:10.0.0.63 Mask:255.255.255.192
inet addr:127.0.0.1 Mask:255.0.0.0
root@linux-host:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.0.0.0 0.0.0.0 255.255.255.192 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 10.0.0.1 0.0.0.0 UG 0 0 0 eth0
root@linux-host:~#Нормально, в первом случае тоже понятно было.
Интересно, какой практический смысл, однако, в этом.
Интересно, какой практический смысл, однако, в этом.
Такой же, какой и в линках /31. Директ-бродкаст — это обычный, нормальный адрес. Ничем не лучше и не хуже всех остальных. Одно полудохлое приложение, которому нужно, чтобы он чем-то отличался от других адресов, и которому никто не мешает перейти на мультикаст — это, конечно, архиважный повод выкинуть в помойку такую долю глобального адресного пространства.
Всё было бы замечательно, если бы это было стандартизировано и всеми признавалось как обычные юникаст-адреса. А сейчас их использование приведёт к большому количеству проблем: нужно разрешать directed-broadcast маршрутизацию на всех роутерах, непонимающие хосты будут отвечать на этот адрес броадкастом на 2 уровне, который будет флудиться во всю подсеть и т.д.
наоборот, ipcalc 10.0.0.1/26:
Address: 10.0.0.1
Netmask: 255.255.255.192 = 26
Wildcard: 0.0.0.63
Network: 10.0.0.0/26 (Class A)
Broadcast: 10.0.0.63
HostMax: 10.0.0.62
Hosts/Net: 62 (Private Internet)
разуй глаза и вспомни что такое broadcast адрес
Address: 10.0.0.1
Netmask: 255.255.255.192 = 26
Wildcard: 0.0.0.63
Network: 10.0.0.0/26 (Class A)
Broadcast: 10.0.0.63
HostMax: 10.0.0.62
Hosts/Net: 62 (Private Internet)
разуй глаза и вспомни что такое broadcast адрес
На предыдущей работе местные айтишники затеяли смену ip-адресации с 10/8 на 192.168/16, чтобы «уменьшить количесво броадкастов», причем без всякого сегментирования.
Я до сих пор задаюсь вопросом, они правда думали, что это что-то изменит или просто решили изобразить бурную деятельность? :)
Я до сих пор задаюсь вопросом, они правда думали, что это что-то изменит или просто решили изобразить бурную деятельность? :)
Может они затеяли комплекс мероприятий по плавной миграции и подключению новых фич и для этого в том числе поменяли адреса. А лошкам просто быстрое объяснение сказали. Всё равно ничего не поймут.
Блин, у меня комп с 1996 года. С 1996 года несколько очень неглупых людей пытались мне объяснить что такое /31. Сегодня я впервые понял…
Почему-то для многих является откровением, что если маска сети 255.255.254.0, то адрес 192.168.1.0 вполне можно назначить какой-нибудь машине.
А не мог бы ты наглядно пояснить, почему для такой маски как 255.255.254.0 адрес 192.168.1.0 допустим, а для «обычной» 255.255.255.255.0 — нет?
Если не вдаваться в детали, первый адрес диапазона будет адресом сети, а последний — широковещательным. Их нельзя использовать для обычных узлов.
Т.е. 192.168.1.0/255.255.255.0 это диапазон 192.168.1.0-192.168.1.255. Адрес сети — 192.168.1.0.
А для 192.168.0.0/255.255.254.0 диапазон будет 192.168.0.0-192.168.1.255. Можно использовать и 192.168.0.255 и 192.168.1.0, они специальными не будут, т.к. находятся внутри диапазона.
Погугли «адрес сети».
Т.е. 192.168.1.0/255.255.255.0 это диапазон 192.168.1.0-192.168.1.255. Адрес сети — 192.168.1.0.
А для 192.168.0.0/255.255.254.0 диапазон будет 192.168.0.0-192.168.1.255. Можно использовать и 192.168.0.255 и 192.168.1.0, они специальными не будут, т.к. находятся внутри диапазона.
Погугли «адрес сети».
Посмотрел. Ну глупости пишете, чо.
в чем глупости??
Какой смысл обсуждать тут хамство и самолюбование в чьем-то персональном блоге? Будет желание, все то же самое можно изложить тут в каментах или отдельным постом без кривляния нормальным тоном — мне не западло ответить и обсудить по делу. Но задача там не в этом, в «смотрите какой я умный». Ну мне не жалко, чо.
о святые макароны, опять этот быдлотролль: lurkmore.ru/Руслан_Карманов? :D
не то чтобы я сильно не согласен со второй после главной идеей этого высера «нубских статей тысячи и они вызывают тонны ненависти», но как-то главная идея «я самый умный и пиздатый, научу вас vtp pruning'у» портит всё блюдо :'(
хотя на мой взгляд нубские статьи доставляют лулзов и повышают самооценку читателю. не вижу в чём тут ненависть. всем известно что читать надо профильную литературу, желательно на английском, если хочется чего-то умненького ^^
ps: ну и да, вброс мимо кассы, ну да ладно.
не то чтобы я сильно не согласен со второй после главной идеей этого высера «нубских статей тысячи и они вызывают тонны ненависти», но как-то главная идея «я самый умный и пиздатый, научу вас vtp pruning'у» портит всё блюдо :'(
хотя на мой взгляд нубские статьи доставляют лулзов и повышают самооценку читателю. не вижу в чём тут ненависть. всем известно что читать надо профильную литературу, желательно на английском, если хочется чего-то умненького ^^
ps: ну и да, вброс мимо кассы, ну да ладно.
ну троль да, нравится он или не нравится дело другое.
Просто я к тому, что надо всегда все проверять, да же техническую литературу :)
Просто я к тому, что надо всегда все проверять, да же техническую литературу :)
Хм, не знал, что это столь крутой персонаж. Погуглив еще чуть-чуть нашел учебный центр, у которого есть сайт, лучшие инструкторы и очередь из клиентов, но нету адреса. Прекольно, чо.
хотите записаться на курсы? :)
atraining.ru
atraining.ru
rfc3330 может быть переосмыслен. ripe начал выдавать адреса из 128.0.0.0/16, не исключено что некоторых других может ждать аналогичная участь.
ps: да, в junos решается волшебством помечающим этот блок как allowed в martains :)
ps: да, в junos решается волшебством помечающим этот блок как allowed в martains :)
что-то зря я запостил не посмотрев в ripe: RIPE NCC was awared about this issue and now reallocate blocks to those
who got addrs from 128.0.0.0/16
отставить панику!11
who got addrs from 128.0.0.0/16
отставить панику!11
Уже таки начал прям выдавать? Спасибо, не знал.
Они вроде еще зимой анонсировали, что распечатают этот блок, а в JUNOS в 11.3R1 таки пока до сих пор:
Вот визгу-то будееет…
Они вроде еще зимой анонсировали, что распечатают этот блок, а в JUNOS в 11.3R1 таки пока до сих пор:
user@router> show route martians | match 128
128.0.0.0/16 orlonger -- disallowed
128.0.0.0/16 orlonger -- disallowed
128.0.0.0/16 orlonger -- disallowed
128.0.0.0/16 orlonger -- disallowed
128.0.0.0/16 orlonger -- disallowed
128.0.0.0/16 orlonger -- disallowed
[...]
Вот визгу-то будееет…
www.gossamer-threads.com/lists/nsp/juniper/31884
ну вот такая драма, да.
ну вот такая драма, да.
Прочел вчера, да. Вообще, странно это. Вот ей богу, не мешало бы иане хотя бы апдейт к rfc3330 выпустить сначала, а уж потом. Да и все равно непонятно, какой дурак возьмет эти адреса. Пиар пиаром, а в текущих инсталляциях — все сейчас все бросят и побегут этот блок из марйтейнов выключать?
Либо это какой-то ход конем по объяснению всем, что, мол, ничего хорошего от IPv4 не ждите. Примерно с год как есть ощущение, что по меньшей мере RIPE в какую-то такую игру стал играть (давно уже выдает адреса направо и налево, имхо).
Либо это какой-то ход конем по объяснению всем, что, мол, ничего хорошего от IPv4 не ждите. Примерно с год как есть ощущение, что по меньшей мере RIPE в какую-то такую игру стал играть (давно уже выдает адреса направо и налево, имхо).
пришла малява от ripe с рекоммендациями сделать так:
set routing-options martians 128.0.0.0/16 orlonger allow
set routing-options martians 191.255.0.0/16 orlonger allow
set routing-options martians 223.255.255.0/24 exact allow
и что временно они не будут выдавать специфики из этих диапазонов. но, таке, очевидно, пичалька. время костылей для ойпи4 наступает. *bursts in tears*
set routing-options martians 128.0.0.0/16 orlonger allow
set routing-options martians 191.255.0.0/16 orlonger allow
set routing-options martians 223.255.255.0/24 exact allow
и что временно они не будут выдавать специфики из этих диапазонов. но, таке, очевидно, пичалька. время костылей для ойпи4 наступает. *bursts in tears*
Временно — это, видимо, до тех пор, пока все коробки Juniper в мире не введут эти команды. А еще есть люди, которые на других вендорах написали роут-мэпы с аналогичным смыслом, задеплоили и ушли в запой.
Да, конец света не за горами. Кстати, хочу констатировать, что за 8 или сколько там месяцев с момента передачи последних /8 рирам, таки и в России стало стыдновато быть магистралом без v6. Так что, глядишь, еще 10 тыс. ведер, и золотой ключик у нас в кармане.
Да, конец света не за горами. Кстати, хочу констатировать, что за 8 или сколько там месяцев с момента передачи последних /8 рирам, таки и в России стало стыдновато быть магистралом без v6. Так что, глядишь, еще 10 тыс. ведер, и золотой ключик у нас в кармане.
Кстати, еще куст травы на могиле классовой адерсации )
Пробежал мельком, решил накинуть 2 цента.
Прежде чем посылать IP-пакет, компьютер определяет, попадает ли адрес назначения в «свою» подсеть. Если попадает, то шлет пакет «напрямую», если же нет — отсылает его шлюзу по умолчанию (маршрутизатору).
Компьютер бегает на 7 уровне osi, а nic карточка только на первом и втором.
Отсюда следует что если нет компьютер ничего не определяет, этим занимается маршрутизаторы и свитчи. Запустите wireshark и поглядите на arp whereis пакеты и тд.
Насчет классов — яничегонепонял.png с какого праздника класс а номерок 10.х.х.х попал у вас в класс С?
Вообщем если вы еще не ccna то рекомендую там много хорошего
Прежде чем посылать IP-пакет, компьютер определяет, попадает ли адрес назначения в «свою» подсеть. Если попадает, то шлет пакет «напрямую», если же нет — отсылает его шлюзу по умолчанию (маршрутизатору).
Компьютер бегает на 7 уровне osi, а nic карточка только на первом и втором.
Отсюда следует что если нет компьютер ничего не определяет, этим занимается маршрутизаторы и свитчи. Запустите wireshark и поглядите на arp whereis пакеты и тд.
Насчет классов — яничегонепонял.png с какого праздника класс а номерок 10.х.х.х попал у вас в класс С?
Вообщем если вы еще не ccna то рекомендую там много хорошего
Очень странно слышать, что классовый подход забыт. Это не так. Не смотря на то, что сейчас в основном используется комбинация CIDR и VLSM, при этом, во многих современных реализациях сетевых протоколов можно наблюдать остатки классового подхода:
1. Автосуммирование в BGP, EIGRP и RIP2 выполняется по границе классовых сетей. Причём в протоколах RIPv2 и EIGRP автосуммирование включено по-умолчанию.
2. RIPv2 не позволяет объявлять супер сеть в качестве суммарного маршрута. Супер сеть в данном протоколе так же не может быть указана в качестве аргумента команды network. Насколько я помню, суперсеть можно добавить в домен RIP только редистрибуцией. Т.е. RIPv2 имеет ограниченую поддержку CIDR.
3. В протоколе RIPv2 команда network позволяет указать только классовые сети. Для EIGRP тоже, если не указана wildcard-маска.
3. Как вообще можно понять работу CIDR, концепции суперсетей и VLSM безотносительно рассмотрения классовой адресации и классовых протоколов маршрутизации? В самых последних экзаменационных материалах Cisco обязательно нужно знать диапазоны классовых сетей и концептуальное устройство классовой адресации. Мне кажется, правильнее формулировать, что существует несколько технологий организации адресации в IP-сетях — классовый подход, маски постоянной длины, VLSM и CIDR. И именно в таком порядке, потому что вполне жизнеспособна комбинация, когда при классовой адресации используется VLSM.
1. Автосуммирование в BGP, EIGRP и RIP2 выполняется по границе классовых сетей. Причём в протоколах RIPv2 и EIGRP автосуммирование включено по-умолчанию.
2. RIPv2 не позволяет объявлять супер сеть в качестве суммарного маршрута. Супер сеть в данном протоколе так же не может быть указана в качестве аргумента команды network. Насколько я помню, суперсеть можно добавить в домен RIP только редистрибуцией. Т.е. RIPv2 имеет ограниченую поддержку CIDR.
3. В протоколе RIPv2 команда network позволяет указать только классовые сети. Для EIGRP тоже, если не указана wildcard-маска.
3. Как вообще можно понять работу CIDR, концепции суперсетей и VLSM безотносительно рассмотрения классовой адресации и классовых протоколов маршрутизации? В самых последних экзаменационных материалах Cisco обязательно нужно знать диапазоны классовых сетей и концептуальное устройство классовой адресации. Мне кажется, правильнее формулировать, что существует несколько технологий организации адресации в IP-сетях — классовый подход, маски постоянной длины, VLSM и CIDR. И именно в таком порядке, потому что вполне жизнеспособна комбинация, когда при классовой адресации используется VLSM.
Про автосаммари мы выше разговаривали. См. чего sahe пишет в частности в этой ветке: habrahabr.ru/post/129664/#comment_4311895 Если хоротко, то это где-то в диапазоне между «говно мамонта» до «причуды реализации одного вендора». С RIP то же самое. Я еще в 2003 году учился в Cisco Academy и ребята там балуясь на доске рисовали могилку и писали «RIP RIP». 10 лет прошло.
То есть ретроспективно, для общего развития, рассказов внукам, пугания детей и проч. — про все это имеет смысл иметь какое-то представление. Если говорить о ликбезе, то нахрен это оно не сдалось.
Кстати, для BGP автосуммаризация, хоть классовая, хоть бесклассовая — это вообще бред сивой кобылы.
Никакой классовой адресации нету. Нету. Забудьте. Есть вендоры, экзамены, книжки, люди, которые это слово употребляют. Да, есть. Ну есть еще люди, которые говорят «лóжить» и «звóнить». Ну есть. Ну говорят.
То есть ретроспективно, для общего развития, рассказов внукам, пугания детей и проч. — про все это имеет смысл иметь какое-то представление. Если говорить о ликбезе, то нахрен это оно не сдалось.
Кстати, для BGP автосуммаризация, хоть классовая, хоть бесклассовая — это вообще бред сивой кобылы.
Никакой классовой адресации нету. Нету. Забудьте. Есть вендоры, экзамены, книжки, люди, которые это слово употребляют. Да, есть. Ну есть еще люди, которые говорят «лóжить» и «звóнить». Ну есть. Ну говорят.
Ну ок, тогда что вы скажете насчёт того, что CIDR-блок определяется, как суммарный блок классовых сетей, по крайней мере в версии Cisco? Причём любые блоки в пределах классовой сети не попадают под определение CIDR. CIDR — это например блок 192.168.0.0/21. Всё что больше 24 для данной сети — это не CIDR.
>и ребята там балуясь на доске рисовали могилку и писали «RIP RIP»
Да, а что Вы скажите про RFC 2080 и RIPng для ipv6?
>Кстати, для BGP автосуммаризация, хоть классовая, хоть бесклассовая — это вообще бред сивой кобылы.
Вы так уверены? А что скажете насчёт этого, цитата из книги 2010 cisco press:
The BGP auto-summary command determines how BGP handles redistributed routes. The no autosummary
router configuration command turns off BGP autosummarization. When summarization is enabled
(with auto-summary), all redistributed subnets are summarized to their classful boundaries in the BGP
table. When summarization is disabled (with no auto-summary), all redistributed subnets are present in
their original form in the BGP table. For example, if an ISP assigns a network of 10.100.50.0/24 to an
autonomous system, and that autonomous system then uses theredistribute connected command to
introduce this network into BGP, BGP announces that the autonomous system owns 10.0.0.0/8 if the autosummary
command is on. To the Internet, it appears as if this autonomous system owns all the Class A
network 10.0.0.0/8, which is not true. Other organizations that own a portion of the 10.0.0.0/8 address
space might have connectivity problems because of this autonomous system claiming ownership for the
whole block of addresses. This outcome is undesirable if the autonomous system does not own the entire
address space. Using thenetwork 10.100.50.0 mask 255.255.255.0 command rather than
the redistributed connected command ensures that this assigned network is announced correctly.
>и ребята там балуясь на доске рисовали могилку и писали «RIP RIP»
Да, а что Вы скажите про RFC 2080 и RIPng для ipv6?
>Кстати, для BGP автосуммаризация, хоть классовая, хоть бесклассовая — это вообще бред сивой кобылы.
Вы так уверены? А что скажете насчёт этого, цитата из книги 2010 cisco press:
The BGP auto-summary command determines how BGP handles redistributed routes. The no autosummary
router configuration command turns off BGP autosummarization. When summarization is enabled
(with auto-summary), all redistributed subnets are summarized to their classful boundaries in the BGP
table. When summarization is disabled (with no auto-summary), all redistributed subnets are present in
their original form in the BGP table. For example, if an ISP assigns a network of 10.100.50.0/24 to an
autonomous system, and that autonomous system then uses theredistribute connected command to
introduce this network into BGP, BGP announces that the autonomous system owns 10.0.0.0/8 if the autosummary
command is on. To the Internet, it appears as if this autonomous system owns all the Class A
network 10.0.0.0/8, which is not true. Other organizations that own a portion of the 10.0.0.0/8 address
space might have connectivity problems because of this autonomous system claiming ownership for the
whole block of addresses. This outcome is undesirable if the autonomous system does not own the entire
address space. Using thenetwork 10.100.50.0 mask 255.255.255.0 command rather than
the redistributed connected command ensures that this assigned network is announced correctly.
Я ничего из ваших рассуждений про определение CIDR-блока не понял. И совершенно не чувствую, чтоб мне это как-то мешало жить :) Приведите точную цитату, может.
Про RIPng тоже был разговор в каментах к этому топику:
habrahabr.ru/post/129664/?reply_to=6951594#comment_4311694
Стр. 14 доклада по моей ссылке там. Доклад этот Стинберген делал на NANOG49, 2009 год. На дату RFC2080 сами поглядите.
Цитата про BGP autosummary объясняет как работает команда, а не зачем нужна автосуммаризация в BGP (заметьте, я говорю не про суммаризацию BGP-префиксов вообще, а про АВТО-суммаризацю). Так вот эта циата — она про то и говорит, что если автосаммари включено, то вместо реального префикса 10.100.50/24 в BGP уйдет 10/8. Это и есть бред сивой кобылы. =В данном случе разговор про суммаризацию по границе класса.
И даже если бы она была бесклассовой, а некий другой «умный» механизм бы из двух соседних префиксов 10.100.50/24 и 10.100.51.0/24 автоматически бы по умолчанию всегда делал 10.100.50.0/23, то это все равно было бредом сивой кобылы. Например потому что BGP — протокол предназначенный для передачи очень большого количество маршрутов (сотен тысяч и миллионов). И выдергивание нескольких префиксов /24 из таблицы, в которой автоматически сделана такая суммаризация, может привести к неадекватно большим вычислительным затратам. Впрочем, это далеко не единственная причина.
Циска — один из немногих вендоров, реализации которой что-то знают про классы адресов. Делает она это не потому что так уж любит классовую адресацию, а потому что выкидывание фич, пусть даже устаревших, из огромной промышленной машины с заказчиками, привычками, миллионо специфический внедренй, документацией (внешней и внутренней), книгами и т. д. — это гораздо сложнее (читай: очень дорого), чем сохранять эти фичи, не трогая их.
Большинство же вендоров вообще не употребляют такие слова как «класс адресов» и «CIDR-блок», потому что никаких других кроме CIDR блоков адресов давно уже нету. И это совершенно никому не мешает.
Знать про все это, в принципе, нужно, для кругозора и вообще, чтоб читать всякие такие старинные RFC и уметь поддержать беседу про RIP.
Про RIPng тоже был разговор в каментах к этому топику:
habrahabr.ru/post/129664/?reply_to=6951594#comment_4311694
Стр. 14 доклада по моей ссылке там. Доклад этот Стинберген делал на NANOG49, 2009 год. На дату RFC2080 сами поглядите.
Цитата про BGP autosummary объясняет как работает команда, а не зачем нужна автосуммаризация в BGP (заметьте, я говорю не про суммаризацию BGP-префиксов вообще, а про АВТО-суммаризацю). Так вот эта циата — она про то и говорит, что если автосаммари включено, то вместо реального префикса 10.100.50/24 в BGP уйдет 10/8. Это и есть бред сивой кобылы. =В данном случе разговор про суммаризацию по границе класса.
И даже если бы она была бесклассовой, а некий другой «умный» механизм бы из двух соседних префиксов 10.100.50/24 и 10.100.51.0/24 автоматически бы по умолчанию всегда делал 10.100.50.0/23, то это все равно было бредом сивой кобылы. Например потому что BGP — протокол предназначенный для передачи очень большого количество маршрутов (сотен тысяч и миллионов). И выдергивание нескольких префиксов /24 из таблицы, в которой автоматически сделана такая суммаризация, может привести к неадекватно большим вычислительным затратам. Впрочем, это далеко не единственная причина.
Циска — один из немногих вендоров, реализации которой что-то знают про классы адресов. Делает она это не потому что так уж любит классовую адресацию, а потому что выкидывание фич, пусть даже устаревших, из огромной промышленной машины с заказчиками, привычками, миллионо специфический внедренй, документацией (внешней и внутренней), книгами и т. д. — это гораздо сложнее (читай: очень дорого), чем сохранять эти фичи, не трогая их.
Большинство же вендоров вообще не употребляют такие слова как «класс адресов» и «CIDR-блок», потому что никаких других кроме CIDR блоков адресов давно уже нету. И это совершенно никому не мешает.
Знать про все это, в принципе, нужно, для кругозора и вообще, чтоб читать всякие такие старинные RFC и уметь поддержать беседу про RIP.
Я согласен, приведёные выше примеры достаточно экзотические и на практике встречаются редко. Хорошо, в таком случае вот Вам вывод фундаментальной команды show ip route в маршрутизаторах Cisco. Информация о маршрутах в данной команде сортируется по правилам классовых сетей, без понимания классовых сетей логика её вывода совершенно не понятна. Поэтому, смело могу утверждать, что инженер обязан знать концепцию классовых сетей, иначе у него будут проблемы с понимаем вывода этой наиважнейшей команды. Итак:
192.168.1.0/27 is subnetted, 2 subnets
D 192.168.1.32 [90/158720] via 192.168.23.2, 00:00:08, FastEthernet0/0
D 192.168.1.0 [90/158720] via 192.168.23.2, 00:00:23, FastEthernet0/0
Эта запись означает, что классовая сеть 192.168.1.0 разбита на несколько подсетей с использованием статической маски /27. Теперь добавим в исходную сеть подсеть с маской /26:
192.168.1.0/24 is variably subnetted, 3 subnets, 2 masks
D 192.168.1.64/26 [90/158720] via 192.168.23.2, 00:00:04, FastEthernet0/0
D 192.168.1.32/27 [90/158720] via 192.168.23.2, 00:03:20, FastEthernet0/0
D 192.168.1.0/27 [90/158720] via 192.168.23.2, 00:03:34, FastEthernet0/0
Вывод команды изменился. Теперь классовая сеть разбита на три подсети с применением маски переменной длины VLSM. Теперь передадим на маршрутизатор суперсеть, или блок CIDR:
192.168.1.0/24 is variably subnetted, 3 subnets, 2 masks
D 192.168.1.64/26 [90/158720] via 192.168.23.2, 00:00:04, FastEthernet0/0
D 192.168.1.32/27 [90/158720] via 192.168.23.2, 00:03:20, FastEthernet0/0
D 192.168.1.0/27 [90/158720] via 192.168.23.2, 00:03:34, FastEthernet0/0
D 192.168.0.0/23 [90/156160] via 192.168.23.2, 00:00:05, FastEthernet0/0
Прошу обратить внимание, что после добавление CIDR-блока сортировка для сети 192.168.1.0/24 не поменялась, т.е. сети данной сети не вошли в CIDR-блок. Что интересно, сам CIDR блок стоит отдельно, т.к. он олицетворяет собой бесклассовый маршрут и его некуда присовокупить. А теперь собственно объясните мне вывод данной команды не прибегая к терминологии VLSM, SVSM, classful, classless и CIDR? Почему для подсетей всегда рисуется нечто, что очень напоминает классовую сеть? А ведь 21 век на дворе!!!
192.168.1.0/27 is subnetted, 2 subnets
D 192.168.1.32 [90/158720] via 192.168.23.2, 00:00:08, FastEthernet0/0
D 192.168.1.0 [90/158720] via 192.168.23.2, 00:00:23, FastEthernet0/0
Эта запись означает, что классовая сеть 192.168.1.0 разбита на несколько подсетей с использованием статической маски /27. Теперь добавим в исходную сеть подсеть с маской /26:
192.168.1.0/24 is variably subnetted, 3 subnets, 2 masks
D 192.168.1.64/26 [90/158720] via 192.168.23.2, 00:00:04, FastEthernet0/0
D 192.168.1.32/27 [90/158720] via 192.168.23.2, 00:03:20, FastEthernet0/0
D 192.168.1.0/27 [90/158720] via 192.168.23.2, 00:03:34, FastEthernet0/0
Вывод команды изменился. Теперь классовая сеть разбита на три подсети с применением маски переменной длины VLSM. Теперь передадим на маршрутизатор суперсеть, или блок CIDR:
192.168.1.0/24 is variably subnetted, 3 subnets, 2 masks
D 192.168.1.64/26 [90/158720] via 192.168.23.2, 00:00:04, FastEthernet0/0
D 192.168.1.32/27 [90/158720] via 192.168.23.2, 00:03:20, FastEthernet0/0
D 192.168.1.0/27 [90/158720] via 192.168.23.2, 00:03:34, FastEthernet0/0
D 192.168.0.0/23 [90/156160] via 192.168.23.2, 00:00:05, FastEthernet0/0
Прошу обратить внимание, что после добавление CIDR-блока сортировка для сети 192.168.1.0/24 не поменялась, т.е. сети данной сети не вошли в CIDR-блок. Что интересно, сам CIDR блок стоит отдельно, т.к. он олицетворяет собой бесклассовый маршрут и его некуда присовокупить. А теперь собственно объясните мне вывод данной команды не прибегая к терминологии VLSM, SVSM, classful, classless и CIDR? Почему для подсетей всегда рисуется нечто, что очень напоминает классовую сеть? А ведь 21 век на дворе!!!
Конечно, если человек в работе использует продукцию компании X, то ему придется изучить концепцию, которые компания X использует в своих продуктах. Если это хвосты классовой адресации — значит надо знать про хвосты классовой адресации, если свитки Торы — надо знать про свитки Торы, принцип запрета Паули — придется и его освоить. При этом осознавая, что компания Y может на все это наплевать и пользоваться противоположными принципами.
Еще, например, цискины экзамены полны вопросов про EIGRP и FrameRelay. Да и слава тебе господи, пусть люди, которые сдают те экзамены, с этим и возятся, причем тут я и моя статья? Ведь ниоткуда не следует, что она предназначена для людей, которые собираются стать специалистами по продуктам Cisco.
Вообще, я выше в каментах где-то писал, что если кто-то воспринимает мои посты в бложике как единственный источник знаний о профессии, то ему лучше бы сразу поискать себе работу в другой области. Я даже не считаю нужным делать дисклеймер на этот счет, потому что нормальным людям и так очевидно, что это не руководство по подготовке к CCIE и даже — к JNCIA.
>Почему для подсетей всегда рисуется нечто, что очень напоминает классовую сеть? А ведь 21
>век на дворе!!!
Основная причина — бабло. Никакая циска ни в каком веке не станет просто так выкидывать на ветер миллионы ради исправления проблемы, которая проблемой не является (плевать на самом деле, как именно отсортированы маршруты в выводе, лишь бы можно было найти нужный не слишком напрягаясь). Всем понятно, что у нее в выводе написано — понятно. Принципы странные? — да и хрен бы с ними. Маркетологи говорят, что если поменять, то продажи возрастут на на миллиард? — не говорят. Есть опасения, что если это поменять, то у людей сломаются говноскрипты и много всякой другой херни, из-за чего начнется вой, нагрузка на TAC и недовольство ключевых заказчиков? — есть. Значит оставляем все как есть.
Логика структуры вывода цискиного show ip route — это повод для анекдотов уже лет десять как. Ее большинство инженеров внутри самой Cisco не понимают, и ничего — живут как-то. Вообще, ахинея такого вот рода
это лучшая иллюстрация тезиса, что про классы адресов давно пора бы забыть.
P. S. По существу — вы второй коммент подряд порете херню, извините. То подкрепляете доводы цитатой, в которой написано прямо обратное, то вывод всей таблицы маршрутизации на экран называете наиважнейшиим навыком. Причем делаете это в довольно-таки хамском и чересчур надменном, простите, тоне.
Если вы хотите сообщить мне, что вы не последний человек в профессии — дык я вам и так верю, можно так не напрягаться. А вот выступать потребителем вашего самовыражения — извините, скучновато.
Еще, например, цискины экзамены полны вопросов про EIGRP и FrameRelay. Да и слава тебе господи, пусть люди, которые сдают те экзамены, с этим и возятся, причем тут я и моя статья? Ведь ниоткуда не следует, что она предназначена для людей, которые собираются стать специалистами по продуктам Cisco.
Вообще, я выше в каментах где-то писал, что если кто-то воспринимает мои посты в бложике как единственный источник знаний о профессии, то ему лучше бы сразу поискать себе работу в другой области. Я даже не считаю нужным делать дисклеймер на этот счет, потому что нормальным людям и так очевидно, что это не руководство по подготовке к CCIE и даже — к JNCIA.
>Почему для подсетей всегда рисуется нечто, что очень напоминает классовую сеть? А ведь 21
>век на дворе!!!
Основная причина — бабло. Никакая циска ни в каком веке не станет просто так выкидывать на ветер миллионы ради исправления проблемы, которая проблемой не является (плевать на самом деле, как именно отсортированы маршруты в выводе, лишь бы можно было найти нужный не слишком напрягаясь). Всем понятно, что у нее в выводе написано — понятно. Принципы странные? — да и хрен бы с ними. Маркетологи говорят, что если поменять, то продажи возрастут на на миллиард? — не говорят. Есть опасения, что если это поменять, то у людей сломаются говноскрипты и много всякой другой херни, из-за чего начнется вой, нагрузка на TAC и недовольство ключевых заказчиков? — есть. Значит оставляем все как есть.
Логика структуры вывода цискиного show ip route — это повод для анекдотов уже лет десять как. Ее большинство инженеров внутри самой Cisco не понимают, и ничего — живут как-то. Вообще, ахинея такого вот рода
82.0.0.0/32 is subnetted, 1 subnets S 82.94.230.130 [1/0] via 129.143.103.77
это лучшая иллюстрация тезиса, что про классы адресов давно пора бы забыть.
P. S. По существу — вы второй коммент подряд порете херню, извините. То подкрепляете доводы цитатой, в которой написано прямо обратное, то вывод всей таблицы маршрутизации на экран называете наиважнейшиим навыком. Причем делаете это в довольно-таки хамском и чересчур надменном, простите, тоне.
Если вы хотите сообщить мне, что вы не последний человек в профессии — дык я вам и так верю, можно так не напрягаться. А вот выступать потребителем вашего самовыражения — извините, скучновато.
Естественно бабло правит миром, но дело не только в этом, Cisco разработчик многих сетевых технологий, которые в процессе были стандартизированы, например, тот же MPLS. Если Cisco оставляет в выводе команды ip route сортировку по классовым сетям, значит в этом есть логика. Незнаю как Вы, а я эту логику прекрасно понимаю, что собственно и пытался Вам донести. Ваш ps несколько неожиданный, я бы сказал, обескураживающий. Мир Вашему дому!
Про автосаммари мы выше разговаривали. См. чего sahe пишет в частности в этой ветке: habrahabr.ru/post/129664/#comment_4311895 Если хоротко, то это где-то в диапазоне между «говно мамонта» до «причуды реализации одного вендора». С RIP то же самое. Я еще в 2003 году учился в Cisco Academy и ребята там балуясь на доске рисовали могилку и писали «RIP RIP». 10 лет прошло.
То есть ретроспективно, для общего развития, рассказов внукам, пугания детей и проч. — про все это имеет смысл иметь какое-то представление. Если говорить о ликбезе, то нахрен это оно не сдалось.
Кстати, для BGP автосуммаризация, хоть классовая, хоть бесклассовая — это вообще бред сивой кобылы.
Никакой классовой адресации нету. Нету. Забудьте. Есть вендоры, экзамены, книжки, люди, которые это слово употребляют. Да, есть. Ну есть еще люди, которые говорят «лóжить» и «звóнить». Ну есть. Ну говорят.
То есть ретроспективно, для общего развития, рассказов внукам, пугания детей и проч. — про все это имеет смысл иметь какое-то представление. Если говорить о ликбезе, то нахрен это оно не сдалось.
Кстати, для BGP автосуммаризация, хоть классовая, хоть бесклассовая — это вообще бред сивой кобылы.
Никакой классовой адресации нету. Нету. Забудьте. Есть вендоры, экзамены, книжки, люди, которые это слово употребляют. Да, есть. Ну есть еще люди, которые говорят «лóжить» и «звóнить». Ну есть. Ну говорят.
Хорошая статья. Можно еще дополнить ссылками на RFC и детальным разбором подсчета сети, как здесь, к примеру — sysadm.pp.ua/internet/network-planning.html
Sign up to leave a comment.
Еще раз про IP-адреса, маски подсетей и вообще