LINUX.ORG.RU
решено ФорумAdmin

Quagga OSPF не передает «соседям» нужный мне маршрут

 ,


0

1

Привет!

Небольшой провайдер. Имею на обслуживании несколько серверов, которые обмениваются маршрутами (клиентами) по OSPF.

Поставили новый сервер. особенность — подключение клиентов через SuperVLAN (если я не ошибаюсь).

Вот данные сервера:

ОС: FreeBSD 10.0-RELEASE. Quagga (version 0.99.21). название сервера «Iota».

Интерфейс в сторону OSPF-соседей:

root@iota:/e/quagga # ifconfig taurus0
taurus0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC>
	ether 00:15:17:28:b1:31
	inet 195.55.85.24 netmask 0xfffffff0 broadcast 195.55.85.31 
	media: Ethernet autoselect (1000baseT <full-duplex>)
	status: active

Интерфейсы которые смотрят в сторону клиентов:

em0.253: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=103<RXCSUM,TXCSUM,TSO4>
	ether 00:15:17:28:b1:33
	inet 10.10.0.1 netmask 0xffffffff broadcast 10.10.0.1 
	media: Ethernet autoselect (1000baseT <full-duplex>)
	status: active
	vlan: 253 parent interface: em0

em0.254: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=103<RXCSUM,TXCSUM,TSO4>
	ether 00:15:17:28:b1:33
	inet 10.10.0.1 netmask 0xffffffff broadcast 10.10.0.1 
	media: Ethernet autoselect (1000baseT <full-duplex>)
	status: active
	vlan: 254 parent interface: em0

em0.255: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=103<RXCSUM,TXCSUM,TSO4>
	ether 00:15:17:28:b1:33
	inet 10.10.0.1 netmask 0xffffffff broadcast 10.10.0.1 
	media: Ethernet autoselect (1000baseT <full-duplex>)
	status: active
	vlan: 255 parent interface: em0

em0.1121: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=103<RXCSUM,TXCSUM,TSO4>
	ether 00:15:17:28:b1:33
	inet 195.55.85.121 netmask 0xffffffff broadcast 193.53.83.121 
	media: Ethernet autoselect (1000baseT <full-duplex>)
	status: active
	vlan: 1121 parent interface: em0

Каждому клиенту свой VLAN. Клиент по DHCP получает или серую IP (с последующим NAT) з пула 10.10.0.0/16 или белую с пула 195.55.85.120/29.

Задача: по OSPF сообщить OSPF-соседям что 195.55.85.120/29 у меня на сервере «Iota».

Уже упростил конфиг Quagga до минимума , но сеть 195.55.85.120/29 или клиент 195.55.85.122 не анонсируются:

! Конфиг для теста
router ospf
! Мой ID и мой IP
 ospf router-id 195.55.85.24

 passive-interface em0
 passive-interface libra0
 passive-interface lo0

! Моя сетевуха в сторону OSPF-соседей
 network 195.55.85.16/28 area 0.0.0.0
 neighbor 195.55.85.17 priority 200

 area 0.0.0.0 authentication message-digest
 area 0.0.0.0 range 195.55.85.120/29

 redistribute kernel
 redistribute connected
 redistribute static

Хотя клиент есть:

root@iota:/e/quagga # ping 195.55.85.122
PING 195.55.85.122 (195.55.85.122): 56 data bytes
64 bytes from 195.55.85.122: icmp_seq=0 ttl=128 time=5.795 ms

В системе маршрут на него есть:

root@iota:/e/quagga # netstat -rnW | grep 85.122
195.55.85.122/32   00:15:17:28:b1:33  US          0     56773   1500 em0.1121

Но в OSPF маршрута на 195.55.85.122 нету. Ни на сервере не вижу в OSPF ни на соседях.

На сервере:

iota_ospfd# show ip ospf database 

       OSPF Router with ID (195.55.85.24)

                Router Link States (Area 0.0.0.0)

Link ID         ADV Router      Age  Seq#       CkSum  Link count
195.55.85.17    195.55.85.17     671 0x80000a37 0x4e51 1
195.55.85.18    195.55.85.18     462 0x8000092c 0x0e8f 1
195.55.85.19    195.55.85.19    1373 0x80000931 0x0293 1
195.55.85.20    195.55.85.20     404 0x8000092b 0x0c8c 1
195.55.85.21    195.55.85.21     466 0x80000935 0xf595 1
195.55.85.22    195.55.85.22     463 0x80000929 0x0c88 1
195.55.85.23    195.55.85.23     675 0x80000a36 0x444a 1
195.55.85.24    195.55.85.24     599 0x80000004 0x6d4f 1
195.55.85.25    195.55.85.25    1264 0x8000092d 0xfd89 1

                Net Link States (Area 0.0.0.0)

Link ID         ADV Router      Age  Seq#       CkSum
195.55.85.23    195.55.85.23     675 0x800004a2 0xa2e7

                AS External Link States
195.55.85.121   195.55.85.24     599 0x80000003 0xade8 E2 195.55.85.121/32 [0x0]

Проверяю наличие маршрута на соседях через show ip ospf routes. IP сервера вижу:

alpha_ospfd> show ip ospf route 
============ OSPF network routing table ============
N    195.55.85.16/28       [10] area: 0.0.0.0
                           directly attached to taurus0

============ OSPF router routing table =============
R    195.55.85.18          [10] area: 0.0.0.0, ASBR
                           via 195.55.85.18, taurus0
R    195.55.85.20          [10] area: 0.0.0.0, ASBR
                           via 195.55.85.20, taurus0
R    195.55.85.21          [10] area: 0.0.0.0, ASBR
                           via 195.55.85.21, taurus0
R    195.55.85.22          [10] area: 0.0.0.0, ASBR
                           via 195.55.85.22, taurus0
R    195.55.85.24          [10] area: 0.0.0.0, ASBR
                           via 195.55.85.24, taurus0
R    195.55.85.25          [10] area: 0.0.0.0, ASBR
                           via 195.55.85.25, taurus0

============ OSPF external routing table ===========
...
N E2 195.55.85.121/32      [10/20] tag: 0
                           via 195.55.85.24, taurus0

IP клиента 195.55.85.122 не вижу нигде.

Почему не анонсируется подсеть? Может быть дело в «SuperVlan»?

Извините за много букв. Что еще нужно показать для прояснения ситуации?

Спасибо! Выручайте, (второй) третий день не ем, не сплю... ;)

С Quagga раньше не работал...



Последнее исправление: Lufa (всего исправлений: 1)

продолжение...

Сделал експеримент.

Смотрю таблицу маршрутизации:

root@iota:/e/quagga # netstat -rnW | grep 85.122
195.55.85.122/32   00:15:17:28:b1:33  US          0     1512   1500 em0.1121

Клиент есть. Но OSPF его не замечает:

iota_ospfd# show ip ospf database 

       OSPF Router with ID (195.55.85.24)

                Router Link States (Area 0.0.0.0)

Link ID         ADV Router      Age  Seq#       CkSum  Link count
195.55.85.17    195.55.85.17       3 0x80000a42 0x385c 1
195.55.85.18    195.55.85.18    1252 0x8000092e 0x0a91 1
195.55.85.19    195.55.85.19     314 0x80000934 0xfb96 1
195.55.85.20    195.55.85.20    1154 0x8000092d 0x088e 1
195.55.85.21    195.55.85.21    1306 0x80000937 0xf197 1
195.55.85.22    195.55.85.22    1243 0x8000092b 0x088a 1
195.55.85.23    195.55.85.23       7 0x80000a41 0x2e55 1
195.55.85.24    195.55.85.24       6 0x80000010 0xb396 2
195.55.85.25    195.55.85.25     194 0x80000930 0xf78c 1

                Net Link States (Area 0.0.0.0)

Link ID         ADV Router      Age  Seq#       CkSum
195.55.85.23    195.55.85.23       7 0x800004ad 0x8cf2

                AS External Link States

Беру и руками добавляю маршрут на клиента на сервере:

root@iota:/e/quagga # route add -host 195.55.85.122 195.55.85.121
add host 195.55.85.122: gateway 195.55.85.121
root@iota:/e/quagga # netstat -rnW | grep 83.122
193.53.83.122      193.53.83.121      UHS         0      194   1500 em0.1121 =>
193.53.83.122/32   00:15:17:28:b1:33  US          0     1512   1500 em0.1121

OSPF его увидел и занес в базу:

iota_ospfd# show ip ospf database 
...
                AS External Link States
195.55.85.122   195.55.85.24      33 0x80000001 0x597a E2 195.55.85.122/32 [0x0]

И соседи увидели!
============ OSPF external routing table ===========

N E2 195.55.85.122/32      [20/20] tag: 0
                           via 195.55.85.24, taurus0

Удаляю «ручной» маршрут:

root@iota:/e/quagga # route delete 195.55.85.122
delete host 195.55.85.122

— пропадает в OSPF локально и у соседей!

------------------------------------------------------------

Получается Quagga не видит маршрута на клиента при старте?

Еще. Vlan-ы оздаются динамически, биллингом. Возможно они создаются раньше чем запускается Quagga и она не перечитывате таблиці маршрутизации, а реагирует только на изменения?

Lufa
() автор топика

Кажется нашел причину. Биллинг добавляет маршрут командой

route add -net 195.55.85.122/32 -iface em0.1122

и Quagga такой маршрут не принимает.

Разберусь — отпишусь.

Lufa
() автор топика

Все зависит от того как добавлять статический маршрут.

Если:

route add 195.55.85.122/32 -iface em0.1121
195.55.85.122/32   00:15:17:28:b1:33  US          0     1512   1500 em0.1121 
Quagga не примет и проигнорирует.

Если:

route add 195.55.85.122/32 195.55.85.121
root@iota:/etc # netstat -rnW | grep 83.12 
195.55.85.122      193.55.85.121      UHS         0      194   1500 em0.1121 => 
Quagga видит маршрут и анонсирует соседям.

Кто обьяснит в чем ей разница? Спасибо.

Lufa
() автор топика
Ответ на: комментарий от Lufa

Не знаю, если не углубляться, я бы сделал

router ospf
network 195.55.85.120 0.0.0.3 area 0.0.0.0
по идее конечно и redistribute должен срабатывать.

The_Ketchup ★★
()
Ответ на: комментарий от frob

не броадкастный а multiaccess

Кстати, если мы прописываем маршрут через интерфейс а не через IP адрес который прибит к этому интерфейсу всё равно должно работать. Как по мне, дак более верно для connected сетей именно через интерфейс писать, а не через адрес. Да, если что то я с FreeBSD не знаком, может дело связано с ОС а не с идеологией.

The_Ketchup ★★
()
Ответ на: комментарий от The_Ketchup

Если в статике вместо NextHop-а интерфейс, то взять готовый MAC и RARP-нуть его Квагга видимо не умеет.

Можешь продолжать «именно через интерфейс писать» для бродкастных сетей сколько влезет. И даже для multiaccess, если видишь разницу.

frob ★★★★★
()

Эпилог

Итак. В моем случае статические маршруты создаются биллингом с указанием имени интерфейса (а не IP) в качестве шлюза.

И созданный маршрут имеет MAC-адрес для указания шлюза.

root@iota:/etc # netstat -rnW | grep 83.12
195.55.85.123/32   00:15:17:28:b1:33  US          0       13   1500 em0.1122

И я так понимаю так как MAC-адрес это уровень 2, Quagga, работающая с уровнем 3 не мочет марать об L2 руки руки и игнорирует его.

Всем спасибо.

P.S. Вот еще бы подсказали как задать статический маршрут с указанием и IP шлюза и интерфейса шлюза. :)

Lufa
() автор топика
Ответ на: комментарий от frob

по поводу:

Если в статике вместо NextHop-а интерфейс, то взять готовый MAC и RARP-нуть его Квагга видимо не умеет.

При чём тут RARP, MAC В ospf database будет только router id и сети которые он имеет. Теперь по поводу

И даже для multiaccess, если видишь разницу.

1. поясни в чём разница между connected сетью и маршрутом который написан через интерфейс?

2. Разница: Non-broadcast multiple-access network

The_Ketchup ★★
()
Ответ на: Эпилог от Lufa

Итак. В моем случае статические маршруты создаются биллингом
с указанием имени интерфейса (а не IP) в качестве шлюза.

А кто так учил делать ? Сам просто подумай, что должна делать система в этом случае. Маршрутизация в интерфейс допустима только для интерфейсов точка-точка. Вот ppp какой-нибудь - это можно. А выдача клиенту 195.55.85.123/32 - это, вообще, праздник какой-то. Поведение ОС клиента может быть непредсказуемым. Я, честно говоря, удивляюсь, что жалоб нет. Хоть бы /31 выдавали. Это, по крайней мере, в RFC 3021 описано.

Или я что-то ещё, более новое, проспал ?

AS ★★★★★
()
Ответ на: комментарий от The_Ketchup

Как по мне, дак более верно для connected сетей именно через интерфейс писать, а не через адрес.

Ага. И вот у тебя eth, и там 20 хостов. Всем твой пакет слать, или как ? А разбираться с частными случами в виде единственного хоста никто не должен, если соответствующего документа нет, конечно.

AS ★★★★★
()
Последнее исправление: AS (всего исправлений: 1)
Ответ на: комментарий от AS

А при чём тут способ отправки. Вид маршрута не отменяет ARP который и определяет кому конкретно на уровне ethernet сети слать этот пакет. И вообще, выбор конкретного получателя пакета идёт уже по законам той среды в которую L2 интерфейс смотрит. С точки зрения OSPF маршрут попадает в базу от этого самого маршрутизатора, а через чего он идёт на самом этом хосте - вообще до фени. Если мы пишем маршрут через IP адрес интерфейса то просматривая таблицу маршрутизации хост определяет выходной интерфейс а потом запускает ARP для адреса назначения и по полученному MAC формирует кадр Ethernet.

The_Ketchup ★★
()
Ответ на: комментарий от AS

на счёт того что выдавать клиентам /32 - согласен это не правильно. Работать конечно будет, но я сторонник /30. Извините господа, не заметил что на интерфейс клиента /32 стоит... И через этот же интерфейс написан маршрут на клиентский адрес. Понял глупость...

P.S. и вообще пора уже переходить на /64 везде и забывать про маски ;)

The_Ketchup ★★
()
Последнее исправление: The_Ketchup (всего исправлений: 3)
Ответ на: комментарий от AS

Ты проспал, что клиенту выдаётся адрес из подсети /29, первый адрес из которой прописан на интерфейсе маршрутизатора.

/32 в данном случае — это аналог RHI.

frob ★★★★★
()
Ответ на: комментарий от The_Ketchup

При том, что Квагге нужен NextHop.

Попробуй прописать на Квагге маршрут в интерфейс.

Если по-твоему ethernet — это NBMA, то я умываю руки.

P.S.
Ты разберись с кашей-то своей, прежде чем пейзан в википедию отправлять...

frob ★★★★★
()
Ответ на: комментарий от frob

Ты проспал, что клиенту выдаётся адрес из подсети /29,
первый адрес из которой прописан на интерфейсе маршрутизатора.

Тут гибридная схема. /29 на сервер маршрутизироватся дожно, но клиенту /32 присваивается из этих /29. :(

Lufa
() автор топика
Ответ на: комментарий от Lufa

Если ты анонсируешь свой /29, то зачем тебе вдогонку слать /32 (если только ты не роутишь на соседе этот /29 в Null)?

frob ★★★★★
()
Ответ на: комментарий от frob

Может заанонсить всю /29 подсеть примерно так:

redistribute static/connected
route add -net 1.1.1.0/29 dev lo
клиентский трафик будет маршрутизироваться нормально за счёт /32 а в OSPF будет общий префикс.

Обычно на серверах доступа так и делают. Анонсят общий префикс, пишут маршрут через Null (чтобы префикс улетел через IGP), а к клиентам трафик ходит по более точным префиксам.

The_Ketchup ★★
()
Последнее исправление: The_Ketchup (всего исправлений: 3)
Ответ на: комментарий от frob

Если ты анонсируешь свой /29, то зачем тебе вдогонку слать /32

Как о не придавал значения... Но не анонсируется ни то ни то, если за онсову брать системные статические маршруты.

Lufa
() автор топика
Ответ на: комментарий от The_Ketchup

redistribute static/connected
route add -net 1.1.1.0/29 dev lo

Да, спасибо.

Просто мне роль OSPF тут становится непонятна. Я с таким же успехом на бордере, который есть шлюзом для всех серверов, статически маршрут /29 пропишу. И Quagga тогда не нужна.

Но вот критикой системы с /32 я озабочен. Думаю что делать...

Lufa
() автор топика
Ответ на: комментарий от The_Ketchup

Если анонсировать наружу /29 и не дропать эту подсеть на соседях, то /32 анонсировать нэнужно. Трафик и так придёт, а дальше OS сама должна справиться его куда надо отправить.

Смысл анонсировать /32 состоит в том, что исключив /29 и анонисируя только используемые «здесь и сейчас» /32 ты не даёшь внешнему миру слать тебе трафик для неиспользуемых адресов из твоей /29.

Надо пояснять зачем?

frob ★★★★★
()
Ответ на: комментарий от Lufa

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

По поводу роли OSPF, так то да - можно и просто статику написать. Просто «Best Practice» не писать статику если маршрутизаторов больше чем один-два, не будешь же ты на каждом ящике все маршруты выписывать. OSPF всё всем сам расскажет.

The_Ketchup ★★
()
Последнее исправление: The_Ketchup (всего исправлений: 1)
Ответ на: комментарий от frob

Если анонсировать наружу /29 и не дропать эту подсеть на соседях,
то /32 анонсировать нэнужно.

Да, понятно.

Смысл анонсировать /32 состоит в том...
Надо пояснять зачем?

Если Вам не трудно, намекните. :)

Lufa
() автор топика
Ответ на: комментарий от The_Ketchup

им надо писать статический маршрут до шлюза и собственно дефолт через шлюз

DHCP

frob ★★★★★
()
Ответ на: комментарий от frob

Ты проспал, что клиенту выдаётся адрес из подсети /29

Совершенно не важно.

/32 в данном случае — это аналог RHI.

В каком RFC описана работа с /32 на ethernet ?

AS ★★★★★
()
Ответ на: комментарий от The_Ketchup

Не делай ни чего. Если биллинг работает - не трогай. Просто твоя схема
подразумевает настройки клиентов, им надо писать статический маршрут до
шлюза и собственно дефолт через шлюз, а это всё как-то очень не
стандартно.

Немного не понял. Клиентам настройки выдает DHCP-сервер. На сервере — только маршрут на интерфейс VLAN делается. 1 маршрут на каждого клиента.

Если конечно есть тяга к прекрасному - то можешь и переделать.

Есть. Сдерживаю себя. В результате, как правило приходит мысль «пусть бы все себе работало».

не будешь же ты на каждом ящике все маршруты выписывать.
OSPF всё всем сам расскажет.

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

Lufa
() автор топика
Ответ на: комментарий от The_Ketchup

клиентский трафик будет маршрутизироваться нормально за счёт /32 а в OSPF будет общий префикс.

route add -net 1.1.1.0/29 dev lo

Это не очень хорошо. Правильно делать не в lo, а в null. Чтобы пакеты на отсутствующие IP умирали, а не бегали по кругу, пока ttl не кончится. Пусть и через lo, но это лишняя нагрузка.

AS ★★★★★
()
Ответ на: комментарий от Lufa

Я так понимаю так решили ради экономии адресного пространства...

Желание я очень понимаю, но это не годится для ethernet и работать может не потому, что, а вопреки. Для PPPoE - годится.

AS ★★★★★
()
Ответ на: комментарий от The_Ketchup

Вид маршрута не отменяет ARP который и определяет кому
конкретно на уровне ethernet сети слать этот пакет.

Каким образом ? Как выбрать правильный шлюз ? Единственный способ тут - вальнуть броадкастом, чтобы все хосты поймали, а тот, кто шлюз, разберётся.

AS ★★★★★
()
Ответ на: комментарий от frob

Если не анонсить /29 а анонсить только /32 то на конечный маршрутизатор не будет валиться всякий мусор типа сканов портов из интернета... Обычно большой префикс где-то завернут на Null и анонсируется по BGP провайдеру, а внутри сети растаскивается более мелкими кусками через OSPF/RIP/IS-IS/...

Если этот самый заворот на Null есть где-то на маршрутизаторах по выше то будет лучше анонсить /32, если нет то тогда /29 лучше забирать весь и убивать лишний трафик на сервере доступа.

Лучше первый вариант - меньше шлака будет летать по внутренней сети, хотя ЛВС обычно быстрая и такая фигня ей не помешает, если конечно DoS-ить не будут :).

The_Ketchup ★★
()
Ответ на: комментарий от Lufa

Если ты анонсируешь всю подсеть используемую для DHCP, то трафик для любого из неиспользуемых адресов будет дропаться на последнем хопе. Если ты анонсируешь только отдельные адреса, то трафик будет дропаться настолько близко к источнику, насколько это вообще возможно. Соответственно твоим загруженным полезным трафиком линкам не придётся пересылать бесполезный мусор.

frob ★★★★★
()
Ответ на: комментарий от Lufa

Правильно делать не в lo, а в null

ОК, спасибо.

Только я имел вииду не dev null, как таковой, а null route так называемый. Не знаю, может быть, в bsd аналог этого - dev null как раз, но надо уточнить. В Linux это

ip route add blackhole 1.1.1.0/29

AS ★★★★★
()
Ответ на: комментарий от The_Ketchup

Лучше первый вариант - меньше шлака будет летать

OK, спасибо.

Lufa
() автор топика
Ответ на: комментарий от frob

Соответственно твоим загруженным полезным трафиком линкам не придётся > пересылать бесполезный мусор.

Да, я понял. Спасибо.

Lufa
() автор топика
Ответ на: комментарий от AS

Погоди, мы смотрим сейчас со стороны маршрутизатора, на котором прописан маршрут через интерфейс. Допустим, у нас есть такой маршрут: route add -host 1.1.1.1 dev eth0

Если серверу прилетит пакет на адрес 1.1.1.1 он пошлет ARP запрос через интерфейс eth0 получит MAC адрес хоста и отправит Ethernet кадр с IP пакетом на тот MAC который придёт в ответ на ARP. В ARP запросе в качестве IP источника будет IP адрес имеющийся на eth0 (не обязательно из этой сети).

На клиенте придется писать маршрут до шлюза и дефол через шлюз:

route add -host 2.2.2.2 dev eth0
route ad default gw 2.2.2.2

При этом не важно какой IP адрес на клиенте. Лишь бы на стороне сервера было известно про этот самый IP клиента... Но это всё адский кривой дизайн :)

The_Ketchup ★★
()
Последнее исправление: The_Ketchup (всего исправлений: 1)
Ответ на: комментарий от AS

Только я имел вииду не dev null, как таковой, а null route

Конечно, я понял.

Спасибо!

Lufa
() автор топика
Ответ на: комментарий от frob

/32 анонсируется соседям через OSPF.

OSPF оставь. С маршрутом, как раз, никаких вопросов. Вопросы - в работе arp на ethernet с хотом c .X/32

Клиент получает свой .X/29 с DG == .1

И что дальше ? У клиента - /32. Опиши, как должен работать ARP для того, чтобы узнать MAC этого самого .1, если он нифига не в сети клиента.

AS ★★★★★
()
Ответ на: комментарий от AS

Опиши, как должен работать ARP для того, чтобы узнать MAC этого самого .1, если он нифига не в сети клиента.

ARP запрос шлется на адрес FF:FF:FF:FF:FF:FF ему на IP до плинтуса. Хост, увидевший в ARP запросе свой IP возьмет MAC для ответа опять же из самого ARP запроса который только что прилетел броадкастом.

The_Ketchup ★★
()
Последнее исправление: The_Ketchup (всего исправлений: 1)
Ответ на: комментарий от The_Ketchup

Если серверу прилетит пакет на адрес 1.1.1.1 он пошлет ARP
запрос через интерфейс eth0 получит MAC адрес хоста

А, ты вон с каком смысле. Ну да, в случае, если такой хост за этим eth0 есть, это, возможно, сработает, как вариант прямого маршрута (как если бы IP из той же сети был бы на интерфейсе). Но как-то это необычно смотрится. И нет, что-то, уверенности, что такой вариант описан где-то в стандартах. Хотя могу ошибаться.

AS ★★★★★
()
Ответ на: комментарий от AS

стандарты тут не причём, это нормальные настройки, точнее не нормальные а удовлетворяющие всем правилам. Просто так ни кто и ни когда не делает. :)

The_Ketchup ★★
()
Последнее исправление: The_Ketchup (всего исправлений: 1)
Ответ на: комментарий от Lufa

Извините. Клиент таки /32 получает. :(

Нет! Я ошибся. Клиенту DHCP /29 выдает. Это маршруты я себе прописал /32.

Lufa
() автор топика
Ответ на: комментарий от The_Ketchup

ARP запрос шлется на адрес FF:FF:FF:FF:FF:FF ему на IP до плинтуса.

Только вот он не шлётся, если dst ip не попадает в сеть на интерфейсе. А если шлётся, это какое-то поведение, которое выходит за рамки того, что было, когда-то, придумано. Вот я и спрашивал, может, после RFC 3021 ещё что-то появилось ?

AS ★★★★★
()
Ответ на: комментарий от Lufa

Тут я выпал из темы.

Клиенту выдается сеть по DHCP при этом на шлюзовом интерфейсе прописывается адрес из другой подсети и с маской /32 ?

The_Ketchup ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.