поведение интерфейса без номера

daniel ng

В IOS XE, когда вы настраиваете неномерированный интерфейс для заимствования адреса из другого интерфейса, кроме loopback, он не отображается в RIB, поэтому не может возвращать трафик. Необходимо настроить статический маршрут, чтобы он указывал на неномерированный интерфейс в качестве выхода. Однако в IOS XR статический маршрут не требуется, несмотря на то, что неномерированный интерфейс не отображается в RIB и FIB. В Junos он также не отображается в RIB, но отображается в FIB. В чем заключается разница между ними, которая вызывает такое поведение?

Cristian Matei

Привет, @daniel ng
Не только туннели RSVP-TE или SR, но и GRE, IPinIP, IPsec; в конечном итоге все они являются формой наложения и, что наиболее важно, типом соединения P2P, поэтому вполне логично, что они просто работают. Использование неномерированного указания на Loopback также было допустимым решением, когда интерфейс был типа P2P, как PPP, PPPoE, IPoE и т. д. То, что вы пытаетесь сделать, не было разработано для использования с немаркированными (если вы выполните отладку ARP, вы увидите, что маршрутизатор жалуется, что запрос ARP отклонен из-за неправильного кабеля, что означает, что интерфейс маршрутизатора не подключен к этой подсети; а WA является настраиваемым статическим маршрутом). Вместо использования статического маршрута, функция, предназначенная для устранения таких случаев, использует опцию
опроса
при определении конфигурации без номера; например, вместо настройки
ip unnumbered Gi1
, используйте
ip unnumbered Gi1 poll
. Подробнее об этой функции: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_ipv4/configuration/xe-16/ipv4-xe-16-book/ip_unnumbered_ethernet_polling_support.pdf В вашем случае, почему бы вам не использовать BVI/BDI, это должно отлично подойти, это действительная и поддерживаемая функция/особенность, и вы избежите любых возможных сложностей, которые могут возникнуть в будущем, в зависимости от того, какие другие функции вам нужно будет добавить (например, динамическая маршрутизация). Спасибо, Кристиан.

Harold Ritter

Привет,
@daniel ng
, Спасибо за подробную информацию. Это довольно необычный, но умный способ использования интерфейса без номера. Я провел быстрое тестирование с IOS-XE, и, похоже, интерфейс, настроенный для «ipv6 unnumbered», не отвечает на запрос соседа (NS), поступающий от устройства, подключенного к тому же интерфейсу. Я добился его работы, добавив статическую запись соседа (см. пример ниже) на хосте, и теперь он работает как часы. Вы всегда можете обратиться к своей команде Cisco, чтобы запросить изменение поведения в соответствии с тем, что вы видите с ipv4, но я сомневаюсь, что они будут это реализовывать, учитывая редкость вашего случая использования. Считайте следующее обходным путем, а не постоянным решением Статическая конфигурация соседа ipv6 на хосте, подключенном к интерфейсу без номера: ipv6 neighbor <адрес интерфейса без номера> GigabitEthernet1 xxxx.xxxx.xxxx Обратите внимание, что для тестирования я использовал другое устройство IOS-XE в качестве хоста. С уважением,
Гарольд Риттер, CCIE #4168 (EI, SP)

Cristian Matei

Привет, @daniel ng
Ответ довольно прост. В конце концов, разные NOS, разная архитектура, а значит, иногда разные результаты для одной и той же функции. Не уверен, что я правильно понял, что вы имеете в виду под «
в IOS XE, когда вы настраиваете немаркированный интерфейс для заимствования адреса из другого интерфейса, кроме loopback, он не отображается в RIB, поэтому не может возвращать трафик. Необходимо настроить статический маршрут, чтобы он указывал на немаркированный интерфейс в качестве выхода». Можете ли вы привести наглядный пример/топологию для этого? Например, если вы используете туннельные интерфейсы с неномерированными, такого требования нет. Если вы используете Ethernet-интерфейс с неномерированным, указывающим на другой Ethernet-интерфейс, каким будет сценарий использования для такого случая? Спасибо, Кристиан.

daniel ng

Извините, неверная информация. Даже для заимствования из loopback требуется статический маршрут. Вы правы, что туннельный интерфейс не требует статического маршрута, как в RSVP-TE и т. п. Я просто столкнулся с ситуацией, когда мне пришлось использовать ту же подсеть, что и другой используемый интерфейс Ethernet, но я не могу изменить это и не могу контролировать другие части сети. Поэтому я использую unnumbered на другом интерфейсе Ethernet с более длинным префиксом в статическом маршруте, чтобы он мог достигать сегмента, напрямую соединяющего его.

daniel ng

Интерфейс моста также был одним из вариантов, пока я не узнал, что не могу изменить интерфейс кредитора из-за наличия активного трафика. Так я и наткнулся на этот нестандартный метод. Для динамической маршрутизации я знаю, что IGP может использовать loopback для пиринга по немаркированным интерфейсам, хотя я не считаю это слишком значимым. PS: обнаружил, что в IOS XE этот метод работает только на немаркированных интерфейсах IPv4. IPv6 фактически не заимствует GUA и генерирует собственный LLA. IOS XR даже не допускает немаркированные интерфейсы на IPv6. Junos аналогичен IOS XE.

daniel ng

Некоторое время тестировал IPv6 без нумерации и обнаружил, что в RIB и FIB нет записей, даже если я настроил статический маршрут. Команда «show ipv6 interface» выдает сообщение «Интерфейс не имеет номера. Используется адрес GigabitEthernet1», но также «Глобальный одноадресный адрес не настроен». Не уверен, действительно ли он что-то заимствует. IPv4 без номера может нормально отображать заимствованный адрес. Кто-нибудь когда-нибудь удавалось заставить IPv6 без номера работать?

Harold Ritter

Привет,
@daniel ng
, Эта команда «ipv6 unnumbered» является лишь подсказкой для выбора адреса источника (RFC6724). Когда локально созданные пакеты ipv6 пересылаются через интерфейс, на котором настроена команда «ipv6 unnumbered <interface x>», адрес ipv6 <interface x> будет использоваться в качестве адреса источника ipv6. Для достижения этого поведения нет необходимости устанавливать какие-либо записи в RIB и FIB. С уважением, С уважением,
Гарольд Риттер, CCIE #4168 (EI, SP)

daniel ng

Я думал, что выбор исходного адреса имеет значение только в том случае, если есть несколько адресов на выбор. В моем тесте в интерфейсе без номера был только один адрес. Другими словами, это нормальное поведение, что адрес не заимствуется? Если да, то какое значение имеет «ipv6 unnumbered», кроме простого включения IPv6 на интерфейсе? PS: повторно протестировано на Junos версии 21.4 или более поздней, где можно заимствовать GUA при генерации собственного LLA.

Cristian Matei

Привет, @daniel ng
Я не вижу никакой связи между IPv6 без номеров и RFC6724, если только
@Harold Ritter
не сможет это прояснить. Функциональность без номеров описана в
RFC5309,
и хотя нет полной ясности в том, чего ожидать от сценариев IPv4 и IPv6 без номеров, понимая архитектуру IPv4 и IPv6, мы должны/можем понять, чего ожидать в обоих случаях, и, конечно, эти ожидания могут быть переопределены каждым поставщиком по мере необходимости, либо потому, что было решено внедрить некоторые новые функции, используя функциональность без номеров, либо потому, что было решено устранить некоторые ограничения/проблемы внутренней архитектуры NOS, используя функциональность без номеров. В IPv4 нет локальной адресации, и с этого мы и должны начать. Чтобы включить функции контрольной плоскости и плоскости данных на интерфейсе, вам нужен IP-адрес, и единственный способ сделать это в IPv4 — это присвоить IPv4-адрес (который в конечном итоге является маршрутизируемым адресом) на интерфейсе или использовать функцию без адресации. В IPv6 локальная адресация была разработана таким образом, чтобы больше не требовалось активировать маршрутизируемые адреса на любом данном интерфейсе, чтобы активировать как плоскость управления (для хостов и сетевых устройств), так и плоскость данных (для сетевых устройств) на интерфейсе IPv6, поскольку в идеале сеть должна обеспечивать транзит от точки A до точки B без необходимости иметь маршрутизируемые адреса на каждом сетевом соединении, что приводит к достаточно серьезным проблемам в отношении масштабируемости, конвергенции и оптимизации. Маршрутизируемые IPv6-адреса требуются для многоскоковой плоскости управления (например, BGP, туннельные протоколы, где можно и нужно использовать Loopbacks) и для определенных услуг, предоставляемых конечным хостам (где вы назначаете маршрутизируемый префикс сегменту сети, обращенному к хостам). Ожидается, что, как объяснялось ранее, любой поставщик может отменить эту выгоду, поскольку использование IPv6 без номера означает, что вы просто включаете IPv6 на канале, а это значит, что канал будет генерировать локальный адрес IPv6 с использованием схемы EUI-64. Я, по крайней мере на данный момент, не вижу сценария, в котором вам понадобилось бы использовать IPv6 без номера, чтобы вы могли заимствовать маршрутизируемое пространство IPv6 из другого интерфейса. Спасибо, Кристиан.

Harold Ritter

Привет
[, @Cristian Matei]
, RFC5309 определяет понятие «ненумерованный» в контексте протоколов маршрутизации по состоянию канала. Я не уверен, как это относится к текущему вопросу, но, возможно, я что-то упустил из сообщения автора. Что касается релевантности RFC6724, команда «ipv6 unnumbered» напрямую влияет на поведение SAS. Пожалуйста, обратитесь к ответу, который я отправил
@daniel ng
. С уважением,
Гарольд Риттер, CCIE #4168 (EI, SP)

Cristian Matei

Привет, @Harold Ritter
В таком случае, как вы можете объяснить следующее поведение: interface GigabitEthernet2 ipv6 address 2001::1/64
!
interface GigabitEthernet4 ipv6 unnumbered GigabitEthernet2
!
Router#ping 2001::1 source gigabitEthernet 2 Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001::1, timeout is 2 seconds:
Packet sent with a source address of 2001::1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
!
Router#ping 2001::1 source gigabitEthernet 4
% No valid source address for destination Спасибо, Кристиан.

Harold Ritter

Привет
[, @Cristian Matei]
, Router#ping 2001::1 source gigabitEthernet 4
% No valid source address for destination Причина этой ошибки, как я уже упоминал, заключается в том, что вы пытаетесь выполнить ping GUA, а интерфейс, указанный в команде «ipv6 unnumbered», не имеет GUA (или ULA, если на то пошло). Единственный доступный адрес ipv6 на Gig4 — это LLA, который отклоняется SAS, поскольку вы выполняете ping GUA. С уважением,
Гарольд Риттер, CCIE #4168 (EI, SP)

Cristian Matei

Привет, @Harold Ritter
Для меня это ожидаемое поведение. Однако это, похоже, противоречит вашему предыдущему заявлению, поэтому я и написал первый комментарий. Если я что-то не так понял, можете объяснить: Эта команда «ipv6 unnumbered» является лишь подсказкой для выбора адреса источника (RFC6724). Когда локально созданные пакеты ipv6 пересылаются через интерфейс, на котором настроена команда «ipv6 unnumbered <interface x>»,
адрес ipv6 <interface x> будет использоваться в качестве адреса источника ipv6
. Спасибо, Кристиан.

Harold Ritter

Привет
[, @Cristian Matei]
, >
адрес ipv6 <интерфейса x> будет использоваться в качестве исходного адреса ipv6
. SAS по-прежнему необходимо проверить действительность исходного адреса. В данном случае исходный адрес LLA будет считаться недействительным, поскольку адрес назначения является GUA. С уважением,
Гарольд Риттер, CCIE #4168 (EI, SP)

Cristian Matei

Привет, @Harold Ritter
Я все это понимаю. Позвольте мне выразиться проще, так как это было моим вопросом с самого начала. Я совершенно не понимаю, какова связь между использованием IPv6 без номеров и RFC6724. Было бы здорово, если бы вы могли сослаться на конкретный раздел RFC и привести пример. Спасибо, Кристиан.

Networks Engineering

поведение интерфейса без номера