Главная страница


ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Phetisov Edward                      2:5020/400     10 Feb 2003  20:31:56
 To : Eugene B. Berdnikov
 Subject : Re: # SNAT и Proxy ARP
 -------------------------------------------------------------------------------- 
 
 "Eugene B. Berdnikov" wrote:
 
 > Phetisov Edward <wert@mb.ru> wrote:
 > >> Вот если вы посмотрите в начало треда с IS , то может просекете, что весь
 > >> базар начался именно из-за того, чтобы принимать пакеты с некоторым адресом
 > >> на интерфейс, на котором этот _HЕ_ прописан. Hу ? Въезжаете по-маленьку ?
 > PE>
 > PE> Прекрасно понимаю, также прекрасно понимаю что в общем случае это
 > PE> невозможно и
 >
 >  Что невозможно? Принять пакет с левым ip-адресом?
 >  Да запросто: нам его прислали, и мы его приняли.
 >
 >  Потому что MAC изернетовского фрейма был наш. Или карточка была в promisc'e.
 >  А какой там внутри ip, и ip ли вообще - это карточку не волнует нисколько. :)
 >
 > PE> использование Proxy ARP в корне неправильно, т.к. простое появление
 > PE> второго маршрутизатора или просто узла с этой функцией в сегменте приведет
 > PE> к появлению плавающих проблем (сегодня работает - завтра нет, что было -
 > PE> хз, и обычно аргументом является "у меня все работало, а у тебя руки из ЖО
 > PE> растут"),
 >
 >  Конкретный пример "плавающих проблем" можно в студию?
 >
 >  А то у некоторых несознательных админов failover именно так и работает,
 >  а люди не догадываются, что вовсе не отказоустойчивую систему делают,
 >  а ищут проблемы на свою задницу. :)))
 
 Время жизни записи в ARP-таблице 30 минут, так что failover - то получитася, но 
 не
 сразу, и строить на это отказоустойчивость, на мой взгляд, стоит только при
 отстутствии или неприменимости других средств (яркий пример альтернативного
 решения -
 HSRP)
 
 >
 >
 > >> Э-э-э-э ! Да вы видать "гуру" ! В туннеле вообще нет проблем с получением
 > >> пакетов не совпадающих с адресом интерфейса. Что воткнули то и дойдет. Я
 > >> вообще удивлен вашей несообразительности : в теме прямо касающейся ARP
 > >> влезть с какой-то ерундой о "нешироковещательной среде" ???
 > PE>
 > PE> Интересно, а Вы вообще проверяете свои утверждения, или же они основаны
 > PE> только на личных представлениях? Hу да ладно,ок, попытаемся
 > PE> проверить работоспособность тунелей с нелокальными адресами
 > PE> (10.253.0.0/16, 10.253.3.3 и 10.253.4.4 никем не используются): host1$
 > PE> iptunnel add tunl1 mode ipip remote 10.253.4.4 local 10.253.3.3 host1$
 > PE> ifconfig tunl1 172.16.1.1 netmask 255.255.255.252 up с одной стороны
 > PE> и host2$ iptunnel add tunl1 mode ipip remote 10.253.3.3 local
 > PE> 10.253.4.4 host2$ ifconfig tunl1 172.16.1.2 netmask 255.255.255.252 up
 >
 >  Так, "local 10.253.3.3" и "local 10.253.4.4" - ОК.
 >
 > PE> дальше пытаюсь пропинговать соседа :)
 > PE> host1$ ping 172.16.1.2
 > PE> PING 172.16.1.2 (172.16.1.2) from 172.16.1.1 : 56(84) bytes of data.
 > PE> From 172.16.1.1: Destination Host Unreachable
 >
 >  Судя по написаному далее адреса 10.253.3.3 и 10.253.4.4 ни на одном
 >  интерфейсе подняты не были, поэтому результат предсказуемый.
 >
 >  А Вы чего хотели?
 >  Чтобы по подъему туннеля ядро начинало принимать пакеты на его
 >  "локальный" адрес? А на каком интерфейсе, простите, если их несколько?
 >  Очевидно, этого не будет.
 >
 >  Более того, если заглянуть в доку на iproute, то там совершенно четко
 >  написано: "local <S> sets fixed local address for tunneled packets.
 >  It must be an address of another interface of this host."
 >  И причина этого ясна.
 
 Hу так я, собственно, опровергал предположение г-на Барабанова о том что "В
 туннеле
 вообще нет проблем с получением
 пакетов не совпадающих с адресом интерфейса. Что воткнули то и дойдет" и
 объяснения о
 том, почему это не работает следовало бы давать ему :)
 
 >
 >
 >  Hо самое смешное не это, а то, что если бы Вы _не_ написали
 >  "local 10.253.3.3" и "local 10.253.4.4" в спецификации туннелей,
 >  резутьтат был бы ровно ТЕМ ЖЕ. Догадываетесь, почему?
 >  Если да, то какая "работоспособность тунелей с нелокальными адресами"
 >  здесь проверяется?
 
 Если честно, то нет времени задумываться над этим вопросом, если объясните - я
 буду
 признателен (без капли иронии)
 
 >
 >
 >  Hint: параметр адреса у local - это кернельный аналог bind(2) для
 >  инкапсулирующих пакетов. Вы можете себе представить, чтобы вызов bind(2)
 >  порождал живой ip-адрес в системе? :) У меня такое не получается.
 >
 >  Hу ладно, вернемся к нашим пингам, здесь есть кое-что интересное.
 >
 > PE> From 172.16.1.1: Destination Host Unreachable
 > PE> From 172.16.1.1: Destination Host Unreachable
 > PE> From 172.16.1.1: Destination Host Unreachable
 > PE>
 > PE> --- 172.16.1.2 ping statistics ---
 > PE> 4 packets transmitted, 0 packets received, 100% packet loss
 > PE>
 > PE> и естественно с другой стороны получается аналогичная штука
 > PE>
 > PE> host2$ ping 172.16.1.1
 > PE> PING 172.16.1.1 (172.16.1.1) from 172.16.1.2 : 56(84) bytes of data.
 > PE> From 172.16.1.2: icmp_seq=2 Destination Host Unreachable
 > PE> From 172.16.1.2: icmp_seq=3 Destination Host Unreachable
 > PE> From 172.16.1.2: icmp_seq=4 Destination Host Unreachable
 > PE> From 172.16.1.2: icmp_seq=5 Destination Host Unreachable
 > PE> From 172.16.1.2: icmp_seq=6 Destination Host Unreachable
 > PE> From 172.16.1.2: icmp_seq=7 Destination Host Unreachable
 > PE> From 172.16.1.2: icmp_seq=8 Destination Host Unreachable
 > PE>
 > PE> --- 172.16.1.1 ping statistics ---
 > PE> 8 packets transmitted, 0 received, +7 errors, 100% loss, time 7065ms
 >
 >  Hадеюсь, Вы обратили внимание на то, что картина пингов совершено
 >  различна: host2 нашел по arp'у host1, посылает ему icmp-последовательности
 >  и получает icmp-ответы (правда, вовсе не echo-reply, если присмотреться),
 >  а вот host1 по arp'у host2 не нашел, и ping дает локальный отлуп.
 >
 >  Расскажите нам, как Вы добились такой асимметрии.
 >  Я, собственно, примерно представляю как, но интересна версия автора... ;)
 >
 > PE> Вспоминаем про Proxy ARP:
 > PE> host1$ sysctl -w net.ipv4.conf.all.proxy_arp=1;
 > PE> host2$ sysctl -w net.ipv4.conf.all.proxy_arp=1;
 > PE>
 > PE> и, как ни странно, получаем получаем аналогичный результат
 >
 >  Угу. Если нужный адрес нигде не поднят, то его вообще не существует,
 >  что и требовалось доказать.
 >
 
 :) см, выше
 
 Пример с натом действительно был некоректен, так что думаю с этим примером
 вопрос
 будет закрыт
 
 --- ifmail v.2.15dev5
  * Origin: Demos online service (2:5020/400)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор 

 Тема:    Автор:    Дата:  
 # SNAT и Proxy ARP   Igor O. Ladygin   31 Jan 2003 13:48:44 
 Re: # SNAT и Proxy ARP   Phetisov Edward   05 Feb 2003 10:45:18 
 Re: # SNAT и Proxy ARP   Aleksey Barabanov   05 Feb 2003 21:53:47 
 Re: # SNAT и Proxy ARP   Phetisov Edward   06 Feb 2003 14:40:54 
 Re: # SNAT и Proxy ARP   Aleksey Barabanov   07 Feb 2003 01:34:33 
 Re: # SNAT и Proxy ARP   Phetisov Edward   07 Feb 2003 16:14:46 
 Re: # SNAT и Proxy ARP   Aleksey Barabanov   08 Feb 2003 00:02:05 
 Re: # SNAT и Proxy ARP   Phetisov Edward   10 Feb 2003 19:54:20 
 Re: # SNAT и Proxy ARP   Aleksey Barabanov   10 Feb 2003 23:54:01 
 Re: # SNAT и Proxy ARP   Eugene B. Berdnikov   08 Feb 2003 06:03:35 
 Re: # SNAT и Proxy ARP   Phetisov Edward   10 Feb 2003 20:31:56 
 Re: # SNAT и Proxy ARP   Kardanev Alexandre   11 Feb 2003 19:56:38 
 Re: # SNAT и Proxy ARP   Eugene B. Berdnikov   12 Feb 2003 06:03:31 
 Re: # SNAT и Proxy ARP   Victor Wagner   12 Feb 2003 13:28:47 
 # SNAT и Proxy ARP   Andrey Melnikov   12 Feb 2003 23:41:12 
 Re: # SNAT and Proxy ARP   Aleksey Barabanov   13 Feb 2003 00:30:34 
 Re: # SNAT and Proxy ARP   Aleksey Barabanov   13 Feb 2003 00:30:33 
 Re: # SNAT and Proxy ARP   Aleksey Barabanov   13 Feb 2003 00:30:34 
 Re: # SNAT и Proxy ARP   Phetisov Edward   06 Feb 2003 15:17:26 
Архивное /ru.linux/10003ce62544.html, оценка 3 из 5, голосов 10
Яндекс.Метрика
Valid HTML 4.01 Transitional