return

Сети для Самых Маленьких. Микровыпуск №5. FAQ по сетевым технологиям

1 октября 2015, 18:42

Пока весь мир с замиранием ждёт 11-го выпуска СДСМ, посвящённого MPLS BGP L3VPN, я решил сделать вольный перевод неплохой статьи Джереми Стреча с Packetlife.net.

Это подборка небольших FAQ для новичков.

#На каком уровне OSI работает протокол Ч?

#Какая разница между маршрутизатором и многоуровневым коммутатором?

#Какая разница между forwarding и control planes?

#Какая разница между MTU и MSS?

#Какая разница между интерфейсами VLAN и BVI?

#Как работает туннельный интерфейс?

#Что означают четыре типа адресов в NAT?

#Могу ли я использовать адрес сети и широковещательный адрес в NAT-пуле?

#Почему нам нужны IP-адреса? Разве нам не хватит MAC-адресации для всего?

#Позволяет ли QoS расширить пропускную способность?


#На каком уровне OSI работает протокол Ч?

Первая вещь, с которой сталкивается любой, кто изучает сети — это модель OSI (Open Systems Interconnection). Это семиуровневая эталонная модель, официально определённая в IOS/IEC 7498-1. Вы встретите её в любой когда либо напечатанной учебной литературе. Это совершенно обычное дело — ссылаться на OSI при обсуждении взаимодействия между протоколами. Так, например, TCP — это протокол четвёртого уровня, и он сидит на шее IP — протоколе третьего уровня.

Но что это значит на самом деле? Кто решает какому уровню принадлежит протокол? Модель OSI была задумана ещё в 70-е годы, как часть семейства протоколов OSI, которая на полном серьёзе позиционировалась как соперник стеку TCP/IP (спойлер: TCP/IP таки выиграл). Если исключить горстку выживших (наверняка, вы слышали про протокол динамической маршрутизации IS-IS), то протоколы OSI сейчас фактически не используются. Однако эталонная модель OSI, описывающая, как они должны были взаимодействовать, живее всех живых. Что, впрочем, заставляет нас привязывать протоколы одного семейства к уровням, определённым для другого.

По большей части всё работает прекрасно: TCP и UDP едут верхом на IP, который в свою очередь передвигается на Ethernet, PPP или чём бы там ни было другом. Но сорокалетняя модель не всегда может удовлетворить нужны современных протоколов. Возьмём для примера MPLS. Часто его относят к уровню 2,5, потому что он работает поверх канального, но ниже сетевого, не осуществляя при этом ни формирования фреймов ни сквозную адресацию (в отличии от IP-адресов, метки MPLS меняются на каждом узле по мере продвижения пакета к точке назначения). Разумеется, добавление нового уровня между двумя другими разрушает стандартную модель.

Строго говоря, ни один протокол из стека TCP/IP не закреплён официально за каким-либо уровнем OSI именно по той причине, что это разные семейства. Яблоки и апельсины. Эталонная модель — это эталон (Прим. переводчика: всё-таки русское название немного не соответствует Reference Model, эталон предполагает свою идеальность и стремление ему соответствовать). OSI помогает иллюстрировать зависимость одних протоколов от других, и кто кем погоняет, но она не может диктовать, как им функционировать.

Но если вдруг кто-то спросит, отвечайте, что MPLS — это протокол третьего уровня.


#Какая разница между маршрутизатором и многоуровневым коммутатором?

В стародавние времена, маршрутизаторы служили для того чтобы передавать пакеты на основе IP-адресов и предоставляли широкий диапазон интерфейсов: Ethernet, E1, Serial, OC-3 итд. В то же время коммутатор передавал пакеты (кадры, прим. для лиги зануд), основываясь на MAC-адресах, и имели только порты Ethernet.

Но в начале 2000-х нашему чёткому пониманию этой разницы пришёл конец — вырисовывались две важные тенденции. Во-первых, появились многоуровневые коммутаторы, которые не просто получили право передавать пакеты, основываясь на IP-адресах, но и участвовать в протоколах динамической маршрутизации, как самые настоящие маршрутизаторы. Во-вторых, операторы начали необратимый процесс миграции с технологий с коммутацией каналов на модерновый Ethernet, предоставляющий высокие скорости за низкую плату. Сегодня совершенно в порядке вещей, если маршрутизатор имеет только Ethernet-интерфейсы, как будто бы он коммутатор.

Где лежит граница между маршрутизатором и многоуровневым коммутатором? Существует ли ещё эта граница?

Фактическая разница между ними сводится к следующим нескольким пунктам:

  • Плотность портов. Коммутаторы уровня Enterprise обычно несут на борту 24 или 48 портов. Иногда они могут стекироваться для ещё большего расширения. Основная цель: засунуть настолько много интерфейсов, насколько позволяет передняя панель. Маршрутизатор напротив обычно имеет намного меньше интерфейсов, возможно, разнесённых по разным сменным платам. (Прим. переводчика: если речь идёт о оборудовании операторского класса, то плотность портов на линейных платах маршрутизатора вполне сравнится с коммутаторскими).
  • Скорость. Коммутаторы созданы для того, чтобы молотить трафик. Сейчас даже скромные офисные коммутаторы зачастую предоставляют пропускную способность на скорости линии. Это достигается засчёт того, что обработка трафика происходит на аппаратных чипсетах без участия CPU. (Прим. переводчика: следует и тут заметить, что и маршрутизаторы сейчас преимущественно используют для передачи трафика FPGA и ASIC и в своей пропускной способности не уступают коммутаторам).
  • Интеллект. Ключевое же различие, которое может вынудить вас выбрать маршрутизатор — интеллектуальная начинка. Маршрутизатор предоставляет такие функции, как NAT, DPI, Stateful файрвол, шифрование итд — всё это, как правило, не поддерживается коммутатором.

Как бы то ни было, современный мир зиждется на оборудовании, изготовленном под конкретные нужды. Однако, если заглянуть в завтра с виртуальными эплайнсами, NFV и SDN, мы приходим к тому, что одна и та же коробочка может выполнять совершенно разные роли в зависимости от своего положения в сети.


#Какая разница между forwarding и control planes?

Для новичков это, несомненно, источник путаницы.

Forwarding plane часто называют Data Plane, а по-русски самый удачный вариант — плоскость коммутации. Её задача — доставить пакет из пункта А в пункт Б. Плоскость коммутации коммутирует.

Control plane — плоскость управления — обслуживает функции предписывающие, как должна работать плоскость коммутации. Плоскость управления управляет.

Вот например, у вас есть маршрутизатор с OSPF. Он обменивается маршрутной информацией с соседними маршрутизаторами OSPF, составляет граф всей сети и вычисляет маршруты. Когда таблица маршрутизации (RIB) построена, маршрутизатор инсталлирует лучший маршрут до каждой известной точки назначения в таблицу коммутации (FIB). Это функции control plane.

Когда тот же маршрутизатор получает IP-пакет, он ищет адрес назначения в своей таблице коммутации, чтобы определить интерфейс, в который пакет нужно отправить. Далее пакет передаётся в буфер выходного интерфейса и затем в кабель. Это функции forwarding plane.

Чувствуете различие? Плоскость коммутации отвечает за приём и передачу пакетов, в то время как плоскость управления — за то, как именно принимается решение о передаче пакета.

Плоскость коммутации реализована, как правило, в железе, иными словами выполняется специальными чипсетами (например, Network Processor обращается к TCAM, чтобы быстро извлечь выходной интерфейс из FIB), не требуя обращения к CPU.

Плоскость управления же работает на CPU и в обычной памяти, что очень похоже на работу персонального компьютера. Дело в том, что уровень управления выполняет очень сложные функции, которые с одной стороны не нужны в реальном времени, а с другой их проблематично реализовать в железе. Например, совершенно не важна задержка в несколько миллисекунд, когда маршрутизатор инсталлирует маршрут в таблицу коммутации, в то время как для уровня коммутации это может быть серьёзной деградацией производительности.


#Какая разница между MTU и MSS?

Maximum transmission unit (MTU) говорит о максимальном объёме данных, который может нести один пакет. Обычно мы говорим о MTU в отношении Etherner (хотя другие протоколы, конечно, тоже имеют свои MTU). MTU по умолчанию на большинстве платформ — 1500 байтов. Это означает, что узел может передать кадр, несущий 1500 байтов полезной нагрузки. Сюда не включены 14 байтов заголовка Ethernet (18 в случае 802.1q) и 4 байта поля FSC. Итоговый же размер кадра 1518 байтов (1522 в случае 802.1q). Многие узлы сейчас поддерживают джамбофреймы (jumbo), для этого стандартный MTU увеличивается до 9000+ байтов.

Maximum segment size (MSS) — это величина характерная для TCP, которая показывает максимальную полезную TCP нагрузку в пакете, фактически это MTU для TCP. TCP MSS вычисляется, исходя из значения Ethernet MTU (а, может, и не Ethernet) на интерфейсе. Поскольку TCP должен втиснуться в кадр Ethernet, MSS должен быть меньше, чем MTU. В идеале MSS должен быть максимально возможным: MTU-размер заголовка IP-размер заголовка TCP.

Предположим MTU 1500 байтов, вычитаем из него 20 байтов IPv4 адреса и ещё 20 байтов TCP и получаем MSS 1460 байтов. IPv6 с его удлинённым заголовком оставит для MSS всего 1440 байтов.

TCP MSS определяется один раз в ходе установления соединения. Каждый узел включает свой MSS в опции TCP в первый пакет (тот, что с флагом SYN), и оба узла выбирают наименьшее значение из двух как MSS сессии. Однажды установленный MSS уже не меняется в течение жизни сессии.


#Какая разница между интерфейсами VLAN и BVI?

VLAN-интерфейс, известный также как SVI (Switch Virtual Interface) или RVI (Routed VLAN Interface) — это виртуальный интерфейс на многоуровневом коммутаторе. Он обеспечивает маршрутизацию и часто служит шлюзом по умолчанию для локального сегмента сети. VLAN-интерфейс обычно ведёт себя и настраивается как физический интерфейс маршрутизатора: на него можно назначить IP, он участвует в VRRP, может иметь ACL итд. Вы можете представить себе, что это физический интерфейс внутри коммутатора, а можете, наоборот, вообразить, что это маршрутизирующий интерфейс вне коммутатора, на котором терминируется данный VLAN.

Bridge group Virtual Interface (BVI) служит похожим целям, но существует на маршрутизаторе, на котором нет концепции VLAN, потому что всего его порты обычно работают на L3 (Прим. переводчика: на маршрутизаторах концепция VLAN вполне может присутствовать). Bridge group заставляет два или более портов работать на L2, разделяя между ними широковещательный домен. BVI связывает интерфейсы в Bridge Group и служит виртуальными L3-интерфейсом для всех сегментов, подключенных к нему. Когда маршрутизатор работает одновременно на L2 и L3, его называют Integrated Routing and Bridging (IRB).

В то время, как VLAN-интерфейс — жизненная необходимость многоуровневого коммутатора, IRB — нишевая вещь, которая может использоваться, например, на точках доступа WiFi.


#Как работает туннельный интерфейс?

Многие люди испытывают трудности с пониманием концепции туннельных интерфейсов (Прим. переводчика: действительно?). Туннелирование — это просто инкапсуляция одних пакетов внутрь других при передаче их между двумя точками. Туннельный интерфейс используется для достижения такой инкапсуляции для маршрутизируемых VPN, которые позволяют защититься и абстрагироваться от топологии нижележащей сети. Существует много методов инкапсуляции, включающие IPSec, GRE, MPLS итд.

Несмотря на то, что туннельный интерфейс имеет виртуальную природу, ведёт себя он как и любой другой, когда дело доходит до маршрутизации, с той лишь разницей, что когда пакет выходит через туннельный интерфейс, он упаковывается в новый пакет, для которого снова принимается решение о маршрутизации. Новый беременный пакет отправляется в среду и достигает в конечном счёте точки назначения. На другом конце туннеля внешние заголовки снимаются, и на свет выходит оригинальный пакет, над которым снова принимается решение о маршрутизации.


#Что означают четыре типа адресов в NAT?

Существует четыре класса IP-адресов в контексте NAT:

  • Inside global
  • Inside local
  • Outside local
  • Outside global

К сожалению, эти термины редко объясняются в документации достаточно понятно.

Каждый из них описывает два атрибута: местоположение (location) и точка зрения (perspective).

Местоположение сообщает о каком узле идёт речь. Внутри сети (до NAT) — Inside; во внешней сети (после NAT) — Outside.

Точка зрения сообщает о том, откуда мы смотрим на этот узел. Изнутри нашей сети — Local; из внешней сети — Global.

Возьмём для примера случай, когда вы с компьютера с приватным адресом 192.168.0.10 хотите зайти по telnet на адрес в Интернете 94.142.241.111. Из пула NAT вам выделен IP-адрес 192.0.2.10. Вот так будет выглядеть таблица трансляций:

R2# show ip nat translations
Pro Inside global Inside local Outside local Outside global
tcp 192.0.2.10:32978 192.168.0.10:32978 94.142.241.111:23 94.142.241.111:23

Разберёмся?

Inside Global — как внутренний узел выглядит извне. Сервер в Интернете действительно видит адрес из вашего пула NAT.

Inside Local — как внутренний адрес выглядит изнутри — приватный адрес компьютера

Outside Local — как внешний адрес выглядит инзнутри — видим его публичный адрес и порт 23.

Outside Global — тут должно быть то, как выглядит внешний адрес извне, но ваш NAT таких трансляций не умеет, поэтому адрес совпадает с Outside Local.


#Могу ли я использовать адрес сети и широковещательный адрес в NAT-пуле?

Да. Во-первых, в контексте пула NAT вообще нет понятий маски адрес сети и широковещательный адрес.

Далее прим. переводчика.

Во-вторых адрес сети и широковещательный адрес определяются маской подсети — без неё они теряют смысл. Поэтому считать ли адрес 192.168.0.255 широковещательным адресом, а 192.168.1.0 адресом сети зависит целиком и полностью от маски: для /23 ответ нет, для /24 и более ответ да, а для /32 снова нет.

Поэтому адрес 192.168.0.255 вы можете не только указать в пуле, но даже настроить на интерфейсе с маской /23.

 


#Почему нам нужны IP-адреса? Разве нам не хватит MAC-адресации для всего?

Когда новичок начинает изучение MAC-адресов, он видит, что они должны быть уникальными глобально. И возникает закономерный вопрос, почему бы не использовать MAC-адреса для сквозной адресации через весь Интернет, не прибегая вообще к IP? Однако существует несколько достаточно весомых причин привлечь IP.

Во-первых, не все сети имеют MAC-адресацию. Вообще такой тип свойственен только семейству 802. Очень легко забыть об этом в мире, где практически всё — Ethernet или его вариации (например IEEE 802.11 WiFi). Но во времена юности Ethernet несколько десятилетий назад буйствовало беззаконие в сфере протоколов: Token Ring, Ethernet, Frame Relay, ATM боролись за место в маршрутизаторе. И обеспечить взаимодействие узлов из Token Ring с узлами из ATM посредством MAC-адресов было проблематично — нужен был протокол сетевого уровня.

Во-вторых, IP-адреса мобильны — они могут назначаться администраторами или даже выдаваться автоматически, в то время, как MAC-адреса вшиты в сетевой адаптер на веки вечные. Технически MAC-адрес, конечно, тоже можно поменять, но это не предполагалось изначально и сейчас нет никаких средств для удобного управления ими.

Но самая главная причина третья — IP масштабируем и может связывать огромные сети, а Ethernet — удел небольших сегментов. Пространство IP-адресов иерархично, MAC-адресов — плоско. 254 узла одной локальной сети могут быть агрегированы в одну подсеть /24. 8 подсетей /24 могут быть агрегированы в одну /21. Это возможно, потому что блоки адресов обычно располагаются рядом в Интернете. Всё, о чём нужно заботиться в этом случае маршрутизатору — как добраться до подсети.

MAC-адреса же каждый сам по себе, так как назначаются псевдослучайным образом на производстве, и два адреса, различающихся только в последнем бите, могут оказаться в диаметральных концах планеты. Если вдруг кому-то взбредёт в голову использовать MAC-адреса для сквозной адресации в Интернете, он столкнётся с тем, что маршрутизаторам будет нужно знать адрес каждого отдельно взятого узла в глобальной сети. Здравствуй, интернет вещей.

Далее прим. переводчика.

Освещённый в оригинальной статье вопрос на самом деле простой — одного отсутствия масштабирования достаточно для того, чтобы отказаться от этой идеи.

Гораздо интереснее обратный вопрос: Почему нам нужны MAC-адреса? Разве нам не хватит IP-адресации для всего?

Тут всё не так однозначно. Почему бы действительно в современном мире, где скоро название стека можно менять на TCP/IP/Ethernet, не отказаться совсем от адресации на L2 и позволить узлам в сегменте взаимодействовать по IP?

ARP больше не нужен — пакет коммутируется по IP (кстати, уже сейчас существуют коммутаторы, которые действительно могут производить IP Learning вместо MAC Learning). Широковещание доступно так же через адрес 255.255.255.255.

При этом, я не предлагаю отказаться от Ethernet или L2 совсем, нет — утот уровень абстракции необходим — сетевой не должен работать напрямую с физическим, заниматься фреймингом, проверкой целостности итд; мы просто убираем адресацию из L2.

Сложность начинается на самом деле при передаче пакета из одной подсети в другую через череду маршрутизаторов. Тут даёт о себе знать широковещательная природа Ethernet. В заголовке IP, адрес назначения фиксирован и не меняется по мере продвижения пакета. Поэтому встаёт вопрос, как правильно переслать пакет между маршрутизаторами. Сейчас как раз для этого используются MAC-адреса Next-Hop. Дело в том, что за Ethernet-интерфейсом маршрутизатора может быть не один соседний маршрутизатор, а два, три, десяток, и здесь придётся добавлять ещё какой-то идентификатор Next-hop. В реальном мире в 99,9% мы используем P2P линии между маршрутизаторами и тут нет необходимости в добавлении адреса Next-hop в пакет — больше ведь и слать некому — просто отправляем кадр в кабель. Тут можно вспомнить PPP, где хоть формально поле «адрес» и есть, но оно фактически не используется.

Но концепция Ethernet, который изначально планировался только для локальных сегментов с пользовательскими машинами, не предусматривает сценарий P2P отдельно.

В итоге адресацию с уровня Ethernet мы не можем убрать. Однако тут до сих пор остаётся вопрос — зачем MAC-адреса, ведь в заголовке Ethernet мы могли бы указывать IP-адрес Next-Hop, который менялся бы также на каждом узле.

В целом это верно, но такой подход ломает идеологию стека протоколов, предполагающую независимость уровней друг от друга. Сейчас, например, легко можно выкинуть Ethernet и вместо него использовать xDSL или PON или, прости Лейбниц, Frame Relay — сложности лишь административные и финансовые. Также, поверх Ethernet технически вы можете пустить собственный сетевой протокол IPЧ — и это всё будет работать с минимальными изменениями (добавить новый Ethertype).

Замечу, что этот вопрос нельзя обсуждать в отрыве от исторического и административного контекста. Даже если мы возьмём на себя смелость предположить, что мы нашли идеальное сочетание идеальных протоколов IP+Ethernet, и ближайшие 300 лет нам не грозят глобальные изменения, нужно помнить, что 20 лет назад мир был другим, как мы уже говорили выше, и Ethernet был лишь одним из. Мы не могли так жёстко связывать сетевой и канальный уровни. А теперь сети, которые уже работают, и нам для этого как правило не нужно прилагать титанических усилий, никто не будет переделывать просто потому, что кажется избыточным одновременное использование IP и MAC-адресации.

Кстати, возможно, вы будете несколько удивлены, но часть описанных идей войдут в нашу с вами жизнь в лице IPv6 с его концепцией Link-Local адресов.


#Позволяет ли QoS расширить пропускную способность?

Среди новичков иногда существует заблуждение, что QoS — это волшебная технология, позволяющая пропихнуть через линию больше пакетов, чем она может. Это не так. К примеру, если ваш интернет-канал ограничен 10Мб/с, вы никогда не сможете отправить в него больше. Задача QoS — отдавать предпочтения одним типам трафика над другими. Таким образом во время перегрузки на линии (при попытке отправить больше 10 Мб/с) менее важный трафик будет отброшен в пользу свободной передачи более приоритетного.

Обычно QoS применяется для того, чтобы защитить трафик реального времени, такой как голос или видеоконференции от трафика, терпимого к задержкам и потерям — WEB, почта, FTP, Torrent итд. Кроме того QoS поможет избежать оккупирования всей полосы передачей большого объёма трафика, типа резервного копирования серверов.

Рассмотрим ситуацию, когда у вас есть офис, подключенный через два канала E1 с общей пропускной способностью 4Мб/с. По этой линии передаётся и голос и данные. Чтобы во время перегрузки голосовой трафик не испытывал деградацию, с помощью QoS можно выделить гарантированную полосу для него. Оставшаяся часть будет доступна для данных. Однако если после этого трафик с данными заметно ухудшится, то QoS уже не поможет — в этом случае придётся расширять канал.Переводчик позволил себе некоторые вольности в русскоязычных терминах, которые позволят, как ему кажется, лучше понять смысл.



Оставайтесь на связи

Пишите нам: info@linkmeup.ru
Канал в телеграме: t.me/linkmeup_podcast
Канал на youtube: youtube.com/c/linkmeup-podcast
Подкаст доступен в iTunes, Google Подкастах, Яндекс Музыке, Castbox
Сообщество в вк: vk.com/linkmeup
Группа в фб: www.facebook.com/linkmeup.sdsm
Добавить RSS в подкаст-плеер.
Пообщаться в общем чате в тг: https://t.me/linkmeup_chat

Поддержите проект:

like 195 views 47653 message 14

14 коментариев

  • Владислав Целина

    Здравствуйте Марат! Очень нравится ваша серия «Сети для самых маленьких», спасибо за ваш труд! Я очень внимательно изучил все ваши выпуски ( реально помогают в решении рабочих вопросов) и столкнулся со следующим вопросом ( надеюсь что уместен к данному FAQ) — не возможности входа в приложения или сайты использующие в настройках внешний IP адресс из внутренней сети (например сайт http://www.pupkov.com висит на сервере со внутренним IP 192.168.1.19:80 на роутере cisco 1921 IP NAT сделан проброс 80 порта на этот сервер, заходя из интернета по http://www.pupkov.com или по внешнему IP мы попадаем на сайт но если из внутренней сети набрать этот же URL или IP то попасть на сайт не возможно). Ранее для работы в сети офиса использовался роутер Lincsys «домашней серии» и такой проблемы не было. В «сети» пишут что это функция NAT loopback и что в cisco IOS эта функция не поддерживается (мнения разняться) в чем и я сомневаюсь — Lincsys тот же cisco только попроще — но важен факт что найти четкий ответ как это настроить я не смог ни на сайте cisco ни в сети! Для вас возможно это вообще не вопрос но для «чайников» вроди меня это проблема! Включение DNS на роутере и указание IP host http://www.pupkov.com 192.168.1.19 проблему не решает есть необходимость для других приложений в том числе мобильных указания внешнего IP и тут ступор! Если вас не затруднит помочь разобраться в каком направлении искать или строки как прописать в конфиге — было бы вообще супер! Спасибо!

    11 марта 2016, 13:57
  • Если я логику понимаю(как мне кажется)возможно тут описка

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

    6 ноября 2015, 12:21
  • про разницу между IP и MAC, и почему-бы не оставить один, скажу Вам так, у меня года 2-3 назад у самого этот вопрос. Проблема была в том, что я плохо понимал что есть маршрутизация, VLAN-ы и SVI и т.д… (при там что я окончил высшее по профильной специальности примерно с 4.7 средним балом на бюджетном отделении, замечательно не правда ли?).
    Вот это на самом деле Во первых:

    Пространство IP-адресов иерархично, MAC-адресов — плоско. 254 узла одной локальной сети могут быть агрегированы в одну подсеть /24. 8 подсетей /24 могут быть агрегированы в одну /21. Это возможно потому, что блоки адресов обычно располагаются рядом в Интернете. Всё, о чём нужно заботиться в этом случае маршрутизатору — как добраться до подсети.

    И

    Если вдруг кому-то взбредёт в голову использовать MAC-адреса для сквозной адресации в Интернете, он столкнётся с тем, что маршрутизаторам будет нужно знать адрес каждого отдельно взятого узла в глобальной сети.

    Этого достаточно для объяснения новичку, остальное уже дебри. про ATM,FR и прочих динозавров я думал «кому нужен вообще этот мусор?:)»

    30 октября 2015, 15:22
  • Пожалуйста, расскажите про BVI в какой-нибудь из статей! Совсем непонятно зачем он нужен…

    12 октября 2015, 16:51
  • Марат, спасибо за перевод. Если бы «потенциальный противник» читал цикл СДСМ с шикарнейшими картинками и анимацией, трудностей «с пониманием концепции туннельных интерфейсов» у них не возникло бы.
    "… хотите зайти по telnet на адрес в Интернете 94.142.241.111" — адрес по телнету действительно доступен, смотрел это кино лет 10 назад.

    5 октября 2015, 13:11
  • BVI интерфейсы относятся к теме IOS XR

    2 октября 2015, 18:07
  • Ну да, в таблице маршрутизации на основе MAC-адресов было бы очень много префиксов /48. И флаппинг при дублировании, которое невозможно отследить.
    У меня вот тоже накопилось некоторое число неясностей. Например, почти во всех источниках по QoS забивают голову всякими формулами, токен бакетами, Bc, Be и пр. Но НИКТО не может простым языком объяснить, что это за bursts такие, и для чего они нужны. И что будет, если их не задавать, а задать, например, только CIR. Мне кажется, это связано с TCP, размерами окна и пр. А раньше казалось, это для того, чтобы странички открывались быстро, а файлы качались на CIR. А также никто не может внятно расписать, когда нужен rate-limit, когда policy-map, чем разные платформы отличаются и пр. Глава по QoS из INE Workbook для подготовки к CCIE мало того, что самая большая после BGP (но BGP мне не страшен), так она еще повергла меня в уныние. Ибо помимо MQC там есть куча способов настройки на разных уровнях. Вегешну прочитал дважды от и до — толку мало, да и старовата она.
    Есть еще несколько мутных мест, но они постепенно проясняются, сейчас все не вспомню.
    Да, еще IPv6, которому уже скоро 20 лет, в котором многие вещи уже Deprecated, и есть куча способов преобразования и туннелирования между IPv4 и IPv6, половина из которых тоже не используется. Судя по темпам внедрения, он то ли не нужен, то ли всех пугает.

    1 октября 2015, 13:14
  • PS: возможно описки и нет, но тогда это «великий и могучий» вводит в заблуждение…

    6 ноября 2015, 13:07
  • Собственно вся соль этих интерфейсов описана в статье. Отдельная статья на эту тему не планируется.
    Пример применения, как и описано в статье — точка доступа. Несколько интерфейсов (медные LAN и интерфейс WiFi) с помощью BVI могут быть объединены в один виртуальный L3-интерфейс. Это, если, например, не поддерживаются VLAN.

    13 октября 2015, 09:17
  • Самый спорный пункт, конечно. Я не понял, какие тут трудности могут возникнуть.

    Кино да, поднимает настроение.

    5 октября 2015, 13:21
  • Это еще почему? Такая возможность есть очень давно в классическом IOS.

    2 октября 2015, 18:15
  • Попробуйте прочитать Day One Deploying Basic QoS от Juniper. Там дана пусть не исчерпывающая, но вполне достаточная информация по QoS. О том как Juniper смотрит на саму концепцию QoS. И примеры, разумеется. Я несколько раз подходил к изучению QoS по материалам Cisco и постоянно бросал. После Juniper прям по-другому взглянул на QoS. Но теперь когда настраиваю QoS на Cisco аж порой передергивает — как все выверено у Juniper и как это сделано у Cisco.

    1 октября 2015, 16:55
  • О, тема QoS! Я тоже перечитал 3 объёмных книги, но до сих пор её не понял. Хотя планирую выпуск про него делать.
    Впрочем, Лёша Кротов обещал осветить QoS всесторонне. Ждёмс.

    1 октября 2015, 13:24
  • я пытаюсь, пока что inter-as l2vpn сильнее меня и сил на QoS нет

    1 октября 2015, 14:56

Ещё статьи

Мысли после Cisco Live US 2019
Подводя итог пятидневному марафону технических инъекций в мозг, хочется сказать, что в обозримом горизонте всё есть код. И это не про скрипты для автоматизации — они уже давно здесь. Речь ...
like 0 7863 2
14 июня 2019
Задача №МВ3.3
Наш новый клиент AS 65504 подключен к нашей сети. И в дальнейшем планирует подключение к другому провайдеру и у него уже есть свой PI-блок адресов. Но на данном этапе, есть ...
like 0 8742 1
15 октября 2013
Анонс telecom № 115. NGFW и измерение их производительности
Тема фаерволов неисчерпаема. Сколько бы их уже у нас ни было, всегда найдётся поовдо записать ещё один. На этот раз продолжаем тему, начатую Павлом Коростелёвым на последнем линкмитапе про нагрузочное ...
like 0 1294 0
6 сентября 2022