Неверная обработка маски (255.255.255.254) на di-804hv F/W: Pre V2.00b06 (в т.ч. и в V1.44b13).

Пример static routing:
работающие маски:
89.179.135.66/32 (255.255.255.255)
89.179.135.67/32 (255.255.255.255)

не работает объединение:
89.179.135.66/31 (255.255.255.254)
работает только маршрут к 89.179.135.66, а к 89.179.135.67 вообще не работает и доступ к этому ип-адресу "блокируется": нет пинга, трайсерт дальше роутера не уходит, выглядит как-будто следующий шлюз этого адреса не знает, и ничего не сообщает, нет "отлупа", просто в win2000 "Превышен интервал ожидания для запроса." для следующего хопа после маршрутизатора

По своей не внимательности стал мучать саппорт корбины, при проверке с масками .255 стало понятно, что всё работает у провайдера, это мой шлюз "косячит".

Уважаемый, саппорт! Пожалуйста, прокоментируйте.

PS. Тестировать на других более старых прошивках не очень хочется, хотелось бы услышать ваш ответ/комментарий сначала.

маска 255.255.255.254 - нерабочая в принципе. Оба IP адреса зарезервированы и рабочих не остается.

Та подсеть из двух адресов, что Вы маршрутизируете, тоже существует не сама по себе. Видимо, она больше. К примеру, 89.179.135.64/29.

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

очень жаль что никто из саппорта ещё не отписался, также замечено что если маска заканчивается на
.254 , то обрабатывается один из двух, последний в маске висит, в данном случае всего два адреса подпадает под маску,
.252, то нормально обрабатываются "три первых адреса", последний, "висит/не проходит"
.248, первые 7 обрабатываются нормально, а последний 8ой не пашет "не проходит/висит".. такая же ситуация: последний не пашет
.240, соответственно 15 работает, 16ый нет....
.224 31/1 ...

вообщем, странно это, "он" что думает что это широковещательный, хотя тоже не пойму... разбиритесь пожалуйста... а то приходится добавлять маршруты с обязательным добавлением с маской 255 последнего в диапазоне, не дало это...

...эти данные для V1.44b13

Очень похоже, что именно так он и "думает".

И еще похоже, что это в чистом виде глюк.

тогда почему во всех работает адрес "адрес сети" тот который равен "адрес and маску" он же служебный... вообще-то обнаружено что "широковещательный адрес блокируется".. и фсё т.е. этот адрес "умирает" и обратится к нему нет возможности... тоже верно и для масок типа 255.255.х.0 ...т.е. последний адрес не будет работать, широковещательный...

и вы правильно поняли, статической таблицей я разруливаю пути к двум провайдерам, RIPv2 приводит к нестабильной работе железок с поднятым впном пптп/л2тп клиентом... а теперь ещё один сюрприз... очень тоскливо, надеюсь разрулят в д-линке это хотя б к релизу прошивки 2.хх, хотя я понимаю выпускать запросы на широковещательные адреса за маршрутизатор черева-то тому, что роутер, а точнее не сам он, а запросы со стороны юзера внутри лок.сети будут вызывать броадккаст шторм, т.к. роутер не сможет маршрутизировать данные сообщения, и провайдер может блочить на порту за такие вещи...

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

Может тогда присмотреться к железкам с двумя WAN'ами, типа DI-LB604 или DFL-210?

Хотя, оборудовние уже куплено, так?

верно, но только линейка dfl'ов ...вот тема (выбор оборудования: балансировка 2х и более каналов с pptp/l2tp) где никто мне не ответил, пусть я не конкретно написал как всё хочу, но не звонить же в офис д-линка и пытаться это устно пообсуждать, хотел чтоб ещё заинтересованые либо просто грамотные граждане ответили, т.к. есть куча опасений/трудностей, которые я ещё даже там не описал, думал постепенно эту тему развить...

...вот например как раньше поднималась проблема последовательно-параллельного соединения di-804hv для обеспечения требуемого функционала... видимо скоро будет новая фаза их, когда корбина в моём сегменте пустит мультикаст, а 804-ый д-линк при поднятом пптп/л2тп клиенте этого делать не умеет, ну и т.п. //два провайдера я разрулил, и когда работала динамическая маршрутизация, всё вообще было шоколадно, сейчас тоже не плохо т.к. стат.маршрутов больше стало, но и аппетиты растут и актуальность RIPv1|v2 даже при количестве маршрутов 32 штуки на устройство остаётся для меня актуальным... т.е. желаемое суммарное количество маршрутов, выше 32х, но минимально необходимое меньше, так что пока живу...

уже есть два di-804hv, для двух провайдеров

...как я написал в предыдущем посте, что рассматривается вариант покупки дфла... 800-ый слишком дорогой, да и никак я понять не могу чем отличаются дфл 210 от 800, два ван + дмз, но в дфл210 ван+дмз, все утверждают, что дмз может быть полноценным ван... тогда понять, балансировку делать может, может ли делать балансировку между логическими интерфейсами ppp (pptp/l2tp) или только между WAN1 и WAN2 (800) и никак не WAN и DMZ (210)... вопросов куча, и создавать кучу тем не хотелось, а там никто не ответил... если будет принципиальная необходимость то и дфл-800 куплю, а если только производительность разная, то видимо 210-ого мне хватит

...т.к. два провайдера. то два ди-804hv нужно, задачу с мультикастом на корбине и di-804hv думал попробовать разрешить с помощью последовательного соединения маршрутизаторов(хотя бы как тестовый вариант), а параллельно к ним ещё одного такого же di-804(604...) Для выхода к др. провайдеру... пока что дфлы мультикаст вроде не пропускают, ктоб точно сказал бы....

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

Возможно, Вы уже нашли сравнительную таблицу DFL'ов, но на всякий случай вот:
http://ftp.dlink.ru/pub/FireWall/DFL-210/Data_Sh/DFL-210+800+1600+2500_A2_Datasheet_v.1.13.pdf

А балансировку DFL-210 делать не умеет. Однако, если подразумевается резервирование, то это реализуемо. Хотя у меня ощущение, что механизмов обнаружения неисправности WAN-порта всего два: наличие соединения и ARP-запрос.

Вроде написано, что IGMP встроен.

Выписки из руководства:

да вот тут кто-то обмолвился, что дфл пока так и не поддерживают igmp, в спеках написано что "в будущих прошивках", но писались они давно, а вот в эмуляторе, вроде всё есть...

...хотя, отписались бы компетентные граждане и сказали, что с такой-то прошивкой работает, и я б половину проблем смог бы решить цивилизованым образом и главное ооочень приемлемым для меня... но пока все молчат не было ни одного, кто б сам тестировал бы либо настраивал, а без этого сложно делать правильные выводы о функционале, ди-804hv тоже должен пропускать игмп, но в определённых конфигурациях этого делать не умеет, может и дфл также, в статик/динамик ип работает, а при поднятии ppp(pptp/l2tp) уже нет...

очень жду коментариев от саппорта, И от тех кто сам настраивал и тестировал

Дайте, пожалуйста, ссылку на эмулятор. Я ещё до покупки искал - не нашел.

вот все опубликованые "наши" и "буржуйские"

...пытаюсь вспомнить был ли на "буржуйском" сайте эмулятор линейки dfl-210/800/1600/2500, кажется был для 800-ого, сейчас нет, хотя я может напутал, на русском от 800-ого тут

я понял ещё в чём дело... на ICMP широковещательный за маршрутизатором отвечает моя железка, останется поснифить, но чувствует моя............. что это именно так, сейчас проверим...

причём отвечает моя железка... так, я надеюсь что я не прав, и просто я уже устал... так что на этом не настаиваю, но если кто обратит внимание и растолкует мне, например, что я ошибаюсь и надо реально брать и разбираться в этом, но кажется это именно так...
т.е. железка имеет на ван порту адрес x.y.z.a/24 шлюз на x.y.z.1 широковещательный на x.y.z.255, вот на него отвечает железка, осталось определить какой интерфейс лан или ван, тогда и будет понятно, ну да ладно, видимо я и вправду устал... на сегодня с меня хватит, а то будет тут полный бред.

Ползволю себе вмешатся, немного не по теме, но возможно это позволит решить именно Вашу задачу весьма и весьма бюджетно.

Я эксплуатировал целый парк 804 и 824, они были вполне вменяемые (за исключением некоторых прошивок, причем не всегда помогала последняя). Но некоторые вещи на них труднореализуемы, а иногда просто невозможно сделать что-то...

Я себе нашел весьма интересное решение - роутер на основе LiveCD. Точнее - просто сборка FreeBSD или Linux, которая уже изначально содержит в себе функционал роутера и firewall, и т.п.

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

Берете старый комп (только лишь бы памяти было 64 или чуть больше), втыкаете столько адаперов, сколько Вам надо интерфейсов (WAN, LAN), грузите (CD, дискета, флеш, HDD) - и у вас готовый прекрасный аппарат.

http://freesco.org/
http://www.ipcop.org/
http://www.pfsense.com/
и самый мне понравившийся - http://m0n0.ch/wall/

P.S. В свое время тоже запарился с двумя WAN - m0n0wall меня выручил, несколько часов настройки по какому-то FAQ (причем русский нашел) и с тех пор я ничего там не делал и не трогал (но там есть свой специалист, может он что-то и менял, но софт и железка до сих пор точно работают). Вполне (ИМХО) надежно, прямо как 824 или 804. Но у меня была самая простая задача - автоматическое резервирование канала.

Надеюсь, что эта информация Вам пригодится

monowall штука конечно хорошая , но я допустим специально слез с компов и перешел сначало на DSL-G604T потом на Sarotech U-Stor NHD-355 , когда понадобился VPN перешел на DI-804HV и ни разу об этом не пожалел потому как железки как говорится заточены под свое дело , от сюда разница в стабильности 200%
вот еслиб в линуксах разбирался то с Sarotech U-Stor NHD-355 до сих порбы не слез да и поддержка у них не фонтан

кстати жалко что длинк не делает таких железок , а то никаких компов с monowallАМИ не надо , и никакие DMZ не нужны