Jump to content
Калькуляторы

"ip unnumbered" + /32 + "no arp-proxy" = проблемы с SOHO-роутерами Проблема с SOHO-роутерами в реализации "VLAN на абонента"

Сделали у себя "vlan на абонента"+"ip unnumbered"+DHCP.

 

В качестве агрегаторов - Cisco Catalyst 3560G,

DHCP - ISC 3-й ветки

 

Первоначально настроили выдачу сетевой маски абонентам равной маске подсети, "прибитой" к соответствующему Loopback, на который терминируются абонентские vlan-ы. Соответственно на абонентских vlan-ах включен arp-proxy (по дефолту для каталистов). Все работало.

 

НО! Есть мнение, что arp-proxy не очень то уместно в рамках "Vlan на абонента"... стоило ли изолировать юзеров на 2-м уровне чтобы тут же фактически объединить их обратно на том же 2-м уровне... К тому же слышал и читал, что arp-proxy сам по себе создает дополнительную не желательную нагрузку на агрегатор и делает его более уязвимым, в частности в случае бродкаст-шторма.

 

Поэтому была предпринята попытка организовать выдачу абонентам сетевых параметров с маской /32 "чтобы все работало только через 3-й уровень".

На агрегаторе создали еще один loopback, к нему "прибили" еще одну подсеть и соответственно настроили ее на DHCP. (Конфиги - ниже).

 

И получилось, что при подключении в качестве абонентского устройства компьютера все работает прекрасно, а вот из числа испытанных SOHO-роутеров заработал только D-Link DIR-100.

С остальными добиться работоспособности не удалось... при этом "каждый не работает по-своему"...

 

D-Link DVG-5004 (VoIP-шлюз+роутер) - сам по себе в режиме роутера работает (с него пингуются все хосты в сети, работает телефония), но подключенные на его LAN-интерфейсы компьютеры доступа к сети не имеют (пингуется LAN IP-интерфейс роутера, но не доступен даже Default Gateway на агрегаторе)

 

Linksys RV042, D-Link DIR-330 - сетевые параметры получают, но не работает вообще ничего (даже сами не могут пропинговать Default Gateway на агрегаторе)

 

Как-то эта картина не обнадеживает...

Вопрос - это я что-то не допилил, или выдавать клиентам /32 принципиально невозможно? Ведь роутеры даже дома используются весьма часто....

 

Ниже - конфиги DHCP и агрегатора.

 

Соответственно в Vlan2024 все работает, а Vlan124 - нет.

 

---------------------- Cisco Catalyst 3560G --------------------------

!

interface Loopback100

description Users_network

ip address A.B.184.1 255.255.255.224

ip ospf network point-to-point

end

!

interface Loopback101

description Users_network

ip address A.B.185.129 255.255.255.128

no ip proxy-arp

end

!

interface Vlan124

description Test Client port1

ip unnumbered Loopback101

ip helper-address <DHCP server IP address>

no ip proxy-arp

end

!

interface Vlan2024

ip unnumbered Loopback100

ip helper-address <DHCP server IP address>

end

 

------------------------------- DHCP ------------------------------

 

subnet A.B.184.0 netmask 255.255.255.224 {

option domain-name-servers A.B.D.E, A.B.D.F;

 

# Test1

class "VLAN2024" {match if binary-to-ascii (10, 16, "", substring(option agent.circuit-id, 2, 2))="2024";}

pool {range A.B.184.4; option routers A.B.184.1; allow members of "VLAN2024";}

 

}

 

subnet A.B.185.128 netmask 255.255.255.128 {

option domain-name-servers A.B.D.E, A.B.D.F;

option subnet-mask 255.255.255.255;

# Test 2

class "VLAN124" {match if binary-to-ascii (10, 16, "", substring(option agent.circuit-id, 2, 2))="124";}

pool {range A.B.185.130; option routers A.B.185.129; allow members of "VLAN124";}

 

}

 

 

 

Share this post


Link to post
Share on other sites

А как без арп железка узнает мак куда слать?

Не хотите арп прокси - придумывайте чтобы как то арпы отдавали хотя бы мак шлюза.

 

Длинк 100 возможно тупо шлёт на 00::00 или ff::ff.

Share this post


Link to post
Share on other sites

Роутеры ZyXel вообще не будут работать с маской /32. Я в мае завёл проблему в helpdesk, а воз и ныне там.

Share this post


Link to post
Share on other sites

proxy-arp не совсем то что вы пишите. Весь трафик идет все равно через аггрегатор, атака arp spoofing невозможна, броадкаст не ходит. Циска на все запросы отвечает своим маком. Нагрузка да чуть выше, но не критично и arp rate-limit выставить никто не мешает.

Я думаю нет смысла в выделении /32, должно же быть p2p, а не все устройства поддерживают :(

Share this post


Link to post
Share on other sites
НО! Есть мнение, что arp-proxy не очень то уместно в рамках "Vlan на абонента"... стоило ли изолировать юзеров на 2-м уровне чтобы тут же фактически объединить их обратно на том же 2-м уровне...
СтОило. Теперь у каждого абонента свой интерфейс, со своими ACL. В случае, когда агрегатором является нормальный роутер, ещё и свои полиси-мапы со скоростями в зависимости от тарифа.

Надо выключить - поменял ACL, повесил route-map - и клиент видит требование об оплате, а не отсутствие соединения.

К тому же слышал и читал, что arp-proxy сам по себе создает дополнительную не желательную нагрузку на агрегатор и делает его более уязвимым, в частности в случае бродкаст-шторма.
Броадкаст-штормы надо гасить другими методами. Никакой агрегатор не справится со штормом, если до него долетят ВСЕ пакеты шторма...

Share this post


Link to post
Share on other sites
А как без арп железка узнает мак куда слать?

Не хотите арп прокси - придумывайте чтобы как то арпы отдавали хотя бы мак шлюза.

 

Длинк 100 возможно тупо шлёт на 00::00 или ff::ff.

Вы вообще о чем?

Речь не о АРП, а о АРП-прокси. У "железки" в любом случае единственная дорога "куда слать" - на агрегатор. Без вариантов. Что без АРП-прокси, что с ним... только во 2-м случае агрегатор сам отвечает на все ARP-запросы если у него есть соответствующий статический маршрут к адресу назначения. Опять же что "писюки" работают без вопросов. Проблема вылезла с "мыльницами".

 

IMHO, дело в конкретной реализации стека протоколов... если при маске /32 на своем интерфейсе хост "знает", что все без вариантов надо слать на "шлюз по умолчанию" - точно как при а-ля ppp (p2p) то все в порядке. "vlan на абонента" он по сути тот же самый p2p и есть. Опять же согласно "модели взаимодействия открытых систем" АКА OSI для протокола верхнего уровня (3-го в данном случае, IP) не должно быть ни какой разницы в реализации интерфейса ниже лежащего уровня (2-го). Т.е. при корректной реализации стека в соответствии с принципами OSI для IP не должно быть разницы - что там ниже - езернет или ppp или что еще. Точно так же и "уровню езернета" не должно быть ни какого дела до того, какую там сетевую маску назначили протоколу вышележащего уровня.

Edited by Wolf-psk

Share this post


Link to post
Share on other sites

Мыльницы походу не могут узнать мак шлюза.

Теоретически, можно попробовать слать им АРП объявления с маком шлюза и его IP, но в кеше вроде не долго держится.

Этот пакет сам шлётся если давать:

ifconfig em0 UP

насколько показали мои эксперименты на 8.1, но в кеше он держится очень не долго, пару секунд.

Можете откапчурить его и посылать в сеть, если будете эксперименты ставить.

 

Поставите IPv6, там не будет ARP %)

Share this post


Link to post
Share on other sites
Опять же согласно "модели взаимодействия открытых систем" АКА OSI для протокола верхнего уровня (3-го в данном случае, IP) не должно быть ни какой разницы в реализации интерфейса ниже лежащего уровня (2-го). Т.е. при корректной реализации стека в соответствии с принципами OSI для IP не должно быть разницы - что там ниже - езернет или ppp или что еще.
В этом случае верхи хотят, а низы не знют куда/как :)

Не забывайте о двойной адресации: MAC и IP.

 

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

 

Как про диагностировать - см выше, анонсить арп шлюза и пинговать.

В любом случае, ИМХО, там в исходниках прошивок править если не одну строчку то с десяток, не больше.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this