Функционал "ip unnumbered"¶

Описание¶

Для экономии ip адресного пространства при работе как правило в режиме IPoE для выдачи ip адресов используется режим ip unnumbered.

Если описать простыми словами, то механизм "ip unnumbreered" предполагает выдачу ip адресов и сетей настроенных на лупбеках для разных клиентских вланов. Рассмотрю это на примере оборудования Cisco, т.к. аналогичные механихмы есть и e Juniper и у Huawei.

Настройка в конфиге¶

В конфиге это выглядит следующим образом:

interface lo1
 description ip unnumbered location
 ip address 172.0.0.254 255.255.255.0
 ip address 1.1.1.0 255.255.255.0 secondary
 ip address 2.2.2.0 255.255.255.0 secondary
 no ip redirects
 no ip unreachables
!
interface Vlan2001
 description ip unnumbered Avenu 1
 ip unnumbered Loopback1
 ip helper-address 10.10.10.10 
 ip helper-address 20.20.20.20
 no ip redirects
 no ip unreachables
!
interface Vlan2002
 description ip unnumbered Avenu 2
 ip unnumbered Loopback1
 ip helper-address 10.10.10.10 
 ip helper-address 20.20.20.20
 no ip redirects
 no ip unreachables
!

В этом примере еще задействовано 2 dhcp сервера 10.10.10.10 и 20.20.20.20.

Клиенты из vlan 2001 и vlan 2002 получают по DHCP адрес из одного из диапазонов ip:

• 172.0.0.0/24
• 1.1.1.0/24
• 2.2.2.0/24

Маршрутизатор в данном случае является DHCP relay для клиента. При получении ip адреса по DHCP в RIB маршрутизатора добавляется "static" или "connected" маршрут /32 (взависимости от настроек биндинга). Соответственно в CEF добавляется инфа об L2 заголовке и Outgoing Interface.

Таким образом формируется связка необходимая для форвардинга пакета в FIBe.

Проблемы при использовании "ip unnumbered"¶

При использовании механизма "ip unnumberred" при его явных "плюсах" есть и "минусы", за которые нужно "платить"... В частности имеется проблема маршрутизации между клиентами одного лупбека если данные клиенты принадлежат одной сети на находятся в разных SVI.

Например, в нашем случае если в влан 2001 и 2002 есть клиенты из сети например 172.0.0.0/24, то маршрутизации между ними не будет и клиентское оборудование будет пытаться напрямую (думая, что оно находится в одном броадкаст домене) отправлять ARP запросы, на которые не будет получать ответы, т.к. по факту клиенты находятся в разных вланах и в разных броадкаст доменах. Проблему можно решить с помощью включение proxy-arp на интерфейсах, но наличие proxy-arp приводит к ряду других проблем... Об этом я возможно напишу отдельную заметку.