Комментарии 26
Простите, но где здесь экономия?
В сети /29 вы не сможете использовать все полученные 8 адресов подсети, а сможете только 6.
это решение обходит данную проблему
Гм. Не «по IP уставу» это.
по уставу) дело в том, что адреса прописаны с маской /32, это своего рода point-to-point
Угу, осталось теперь рассказать как-то всему интернету, что на адресе сети и на broadcast-адресе у вас хост, а не то, что там должно быть по стандартам.
И если с адресом сети попроще (в nix-ах как-то относительно подзабили на то, что этот адрес особенный), то вот с машиной на broadcast жить будет весело, ага.
И если с адресом сети попроще (в nix-ах как-то относительно подзабили на то, что этот адрес особенный), то вот с машиной на broadcast жить будет весело, ага.
Понятия адреса сети и бродкаст адреса это исключительно понятия вашей сети. Для интернета эти адреса маршрутизируются одинаково. Если бы я использовал на клиентах в настройках сети 46.4.205.64/29, то для них существовал бы адрес сети .64 и броадкаст .72. А у меня /32. Для кого .72 является бродкастом?
> я использовал на клиентах
Всем по*й, как ты настроил «клиенты». Маршрутизацией сети 46.4.205.64/29 занимается вышестоящее железо. А в RFC написано дропать пакеты с src 46.4.205.64 для сети 46.4.205.64/29.
Ну а вешать broadcast адрес на интерфейс — это вообще много ума иметь надо.
Всем по*й, как ты настроил «клиенты». Маршрутизацией сети 46.4.205.64/29 занимается вышестоящее железо. А в RFC написано дропать пакеты с src 46.4.205.64 для сети 46.4.205.64/29.
Ну а вешать broadcast адрес на интерфейс — это вообще много ума иметь надо.
> А в RFC написано дропать пакеты с src 46.4.205.64 для сети 46.4.205.64/29
Можно ссылочку?
Можно ссылочку?
https://tools.ietf.org/html/rfc2644, section 3, например.
помоему вы путаете. хетнцер дает мне 8 адресов, /29. я могу их использовать как мне удобно. могу организовать шлюз .65, «клиенты» 66-71. тогда у меня будет бродкаст 72, и данная рекомендация
>>https://tools.ietf.org/html/rfc2644
будет по отношению к этому шлюзу
>> дропать пакеты с src 46.4.205.64 и .72 для сети 46.4.205.64/29. понятие бродкаст адреса лежит в рамках одного бродкаст домена, а не всего интернета. завтра мне захочется поделить мою /27 на две /28 и у меня станет уже два бродкаста. И мне рекомендуют (https://tools.ietf.org/html/rfc2644) закрыть хождение пакетов от бродкаста через мой шлюз, потому что если извне через шлюз придет пакет с dest_ip бродкаста моей подсети, на него ответят все узлы этой подсети
представленная сеть не имеет шлюза, не имеет бродкаст-доменов в полном их понимании, там маршрутизируются /32 адреса и на крайний адрес ответит только он и никто больше, потому что пакет придет не через шлюз в бродкаст домен, он придет конкретно к узлу с адресом .72 или .64
>>https://tools.ietf.org/html/rfc2644
будет по отношению к этому шлюзу
>> дропать пакеты с src 46.4.205.64 и .72 для сети 46.4.205.64/29. понятие бродкаст адреса лежит в рамках одного бродкаст домена, а не всего интернета. завтра мне захочется поделить мою /27 на две /28 и у меня станет уже два бродкаста. И мне рекомендуют (https://tools.ietf.org/html/rfc2644) закрыть хождение пакетов от бродкаста через мой шлюз, потому что если извне через шлюз придет пакет с dest_ip бродкаста моей подсети, на него ответят все узлы этой подсети
представленная сеть не имеет шлюза, не имеет бродкаст-доменов в полном их понимании, там маршрутизируются /32 адреса и на крайний адрес ответит только он и никто больше, потому что пакет придет не через шлюз в бродкаст домен, он придет конкретно к узлу с адресом .72 или .64
Ещё раз подумал. В принципе, если в не будете организовывать именно подсети у себя и таковую не будет подразумевать маршрутизирующий вам этот диапазон IP софт, то, действительно, пофигу на бродкасты.
А в XenServer починили OpenSwitch который вырубал на сервере инет, от любого школо доса?
К счастью не сталкивался с такой ситуацией) поэтому не в курсе
Не так давно хецнер прилепили защиту от ддоса. Правда пока не понятно, на сколько эффективно она работает.
Не совсем понятно почему
а не сразу
#xe network-param-set uuid=uuid other-config:static-routes=46.4.205.64/29/172.16.1.10
#xe network-param-set uuid=uuid other-config:static-routes=46.4.205.64/29/172.16.1.1
а не сразу
#xe network-param-set uuid=uuid other-config:static-routes=46.4.205.64/29/172.16.1.10
Задача Network 1 — организовать сетевую доступность между виртуальными машинами и dom0. Network 0 наверное можно было бы обойтись, если назначить alias интерфейсу xenbr0 с адресом приватной сети 172.16.1.1/24.
Но без использования приватной сети мне решения не видится
Но без использования приватной сети мне решения не видится
Эм… А в чем новость то? У них, вроде, на сайте это указано.
А сеть настраивал без доп. скриптов. Надо только создать серую сетку, чтобы не создавать мост. Дебиан умеет point-to-point, вот, что прописывается на госте:
А сеть настраивал без доп. скриптов. Надо только создать серую сетку, чтобы не создавать мост. Дебиан умеет point-to-point, вот, что прописывается на госте:
iface eth0 inet static
address 123.123.123.123/32
netmask 255.255.255.255
gateway 192.168.0.1
pointopoint 192.168.0.1
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Hetzner, сэкономить адреса IPv4 для виртуальных машин XenServer