Резервирование IPOE с DHCP

[Skylaer]

Есть часть сети, выглядит так

 

А --------- Б ---------- В

 

Точки А и В еще имеют прямой линк.

Сейчас в точках А и В расположены PPPOE сервера.

Все прекрасно резервируется.

 

Еще с точки А раздается по DHCP через опцию 82.

Хочется это дело тоже зарезервировать с точки В, чтобы и DHCP там был резервный

и при падении канала АБ, клиенты просто работали в точку В..

 

Как красивее сделать?

[arseniiv]

А какое оборудование? А то телепаты в отпусках

 

И зачем вам вместе PPPoE и opt.82?

[Skylaer]

PPPOE так, для примера, забудьте.

 

Оборудование простое - catalyst 3750G-12S, раздает IP по DHCP, которые берет с помощью Freeradius в базе.

[arseniiv]

VRRP HSRP не подходит?

[dmvy]

убирайте ip unnumbered, делайте dhcp snooping с ip source guard на доступе и включайте vrrp.

[s.lobanov]

убирайте ip unnumbered, делайте dhcp snooping с ip source guard на доступе и включайте vrrp.

 

А потом плачьтесь на тему high cpu usage...

 

------

 

Когда у вас 2 pppoe-сервера, то в случае выхода одного из строя, у вас рвётся сессия и устанавливается новая(~1.5 минуты, если PADT от сервера не было). В случае с DHCP всё абсолютно аналогично, просто ставите lease time порядка минуты.

 

Ну а если красиво, то hsrp/vrrp/carp

[arseniiv]

В случае с DHCP всё абсолютно аналогично, просто ставите lease time порядка минуты.

 

Так все равно получается high cpu usage. DHCP-сервер только ибудет что на renew отвечать.

[s.lobanov]

Ну Вы не сравнивайте high cpu usage на свитчах и на серверах. Даже если у вас случится high cpu usage на сервере, с этим понятно что делать, а когда начинает умирать проц на свитчах, то начинаешь понимать, что дизайн сети унылое говно.

[arseniiv]

Не согласен. Нужно думать не только о своей инфраструктуре но и о клиентской.Я не думаю, что будет правильно если клиентские компы каждые 30 секунд будут пытаться обновить адрес. время аренды менее получаса - это как раз вариант плохого дизайна.

[s.lobanov]

Я не думаю, что будет правильно если клиентские компы каждые 30 секунд будут пытаться обновить адрес. время аренды менее получаса - это как раз вариант плохого дизайна.

 

Т.е. ppp lcp каждые 30 секунд это нормально, а dhcp-request, выполняющие ровно ту же самую функцию(keep-alive) это плохо?

 

Вообще, в IPv4OE 2 основных метода поддержания сессии:

1. dhcp-request с интервалом 30-60 секунд

2. arp-ping с интервалом 30-60 секунд (такое умеют нормальные bras-ы)

 

Чем время аренды 60 секунд хуже чем ваши 1800 секунд? Для клиентского устройства это такая большая проблема раз в 30 секунд слать запрос?

[nnm]

Т.е. ppp lcp каждые 30 секунд это нормально, а dhcp-request, выполняющие ровно ту же самую функцию(keep-alive) это плохо?

 

То, что dhcp-request может выполнять ту же функцию не означает, что он для нее хорошо подходит. Обработка DHCP-request требует больше ресурсов, чем lcp echo. LCP Echo request - простой пакет, Echo reply делается из него заменой нескольких байт. Сравните с DHCP-request, с его огромным, в сравнении с LCP, header-ом и опциями переменной длины. По этой причине 'нормальные bras-ы' умеют отвечать LCP echo непосредственно с линейных карт, не напрягая RP. А вот делать это для DHCP не может никто. Потому что сложно очень.

 

Вообще, в IPv4OE 2 основных метода поддержания сессии:

2. arp-ping с интервалом 30-60 секунд (такое умеют нормальные bras-ы)

А поскольку клиент этого arp-ping не умеет, то он и не узнает, что BRAS пропал. И DHCP транзакцию не запустит.

[s.lobanov]

А поскольку клиент этого arp-ping не умеет, то он и не узнает, что BRAS пропал. И DHCP транзакцию не запустит.

 

arp-ping инициирует bras. Может я не совсем правильно это называю, но смысл такой, что bras периодически шлёт who-has (т.е. стандартный arp пакет), на который все умеют отвечать

 

Т.е. ppp lcp каждые 30 секунд это нормально, а dhcp-request, выполняющие ровно ту же самую функцию(keep-alive) это плохо?

 

То, что dhcp-request может выполнять ту же функцию не означает, что он для нее хорошо подходит. Обработка DHCP-request требует больше ресурсов, чем lcp echo. LCP Echo request - простой пакет, Echo reply делается из него заменой нескольких байт. Сравните с DHCP-request, с его огромным, в сравнении с LCP, header-ом и опциями переменной длины. По этой причине 'нормальные bras-ы' умеют отвечать LCP echo непосредственно с линейных карт, не напрягая RP. А вот делать это для DHCP не может никто. Потому что сложно очень.

 

 

Совершенно согласен. Именно поэтому я и озвучил второй вариант, когда у нас не самопальный брас на PC, а что-то "нормальное"

 

В случае брас, сляпанных из обычного сервера, там не так критично будет(использовать arp-ping или dhcp-request в качестве кипаливов), поскольку даже нет разделения data plane и control plane (конечно можно говорить о kernel space и user space, но всё равно и то и то кушает один и тот же ресурс - CPU)

 

 

UPD: cisco называет arp keepalive'ы arp-ping'ом. вот тут можно посмотреть наглядно http://www.ciscoexpo.ru/club/sites/default/files/seminar_attachments/service-edge-v.1.0.pdf

Edited November 8, 2012 by s.lobanov

[dmvy]

3750 нужно использовать только как dhcp_relay без ip unnumbered и нагрузка будет только на сам DHCP-сервер. а если не использовать ip unnumbered, то и время лизы может быть вполне 5/10/20 минут.

[Skylaer]

И чем поможет время лизы в 10/20 минут? Мне бы failover получить, а не устаревшую лизу :)

И тут еще момент - никто не знает, упал ли участок Б-В или нет.

 

В общем пока решения я не вижу :(

[dmvy]

И чем поможет время лизы в 10/20 минут? Мне бы failover получить, а не устаревшую лизу :)

И тут еще момент - никто не знает, упал ли участок Б-В или нет.

 

В общем пока решения я не вижу :(

failover выполнит vrrp. я же начал с того, что 3750 про dhcp-сесии ничего не должен знать. т.е. ip helper на int vlan, где прописаны подсети. а защиту от ip spoffing делать на коммутаторах доступа, которые добавляют opt82.

[Skylaer]

VRRP не выполнит failover, если между 3750 есть линк, а пропал только линк к клиентам.

[rus-p]

VRRP не выполнит failover, если между 3750 есть линк, а пропал только линк к клиентам.

 

Если обмен VRRP завернете только в линк АБВ, то отработает.

В чем проблема ?