[Jugernault]

Господа, что то у меня полный ступор - не едут лыжи, хоть ты убейся. Может кто чего подскажет?

 

Ситуация следующая:

В наличии имеется софтовый PPPoE BRAS - CentOS 5.4, ядро ванильное 2.6.31.13, четыре гигабитных интерфейса (два в сторону ядра - Intel 82574L, два в сторону клиентов - Intel 82576, на всех по две раздельных очереди rx и tx).

На BRASе zebra+ospfd (quagga-0.99.15-2009082801), в сторону ядра еqual-cost multi-path routing:

[root@xxx~]# ip route

...

...

default proto zebra src XXX.YYY.ZZZ.17 metric 11

nexthop via AAA.BBB.CCC.65 dev eth0 weight 1

nexthop via AAA.BBB.CCC.69 dev eth1 weight 1

...

К BRASу коннектиться клиент (PPPoE сервера живут на интерфейсах eth2 и eth3, IP адресов интерфейсы не имеют) и живет себе припеваючи:

[root@xxx~]# ip addr show dev ppp641

4756: ppp641: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1400 qdisc htb qlen 3

link/ppp

inet XXX.YYY.ZZZ.17 peer 10.195.12.97/32 scope global ppp641

 

[root@xxx~]# ip route get 10.195.12.97

10.195.12.97 dev ppp641 src XXX.YYY.ZZZ.17

cache mtu 1400 advmss 1360 hoplimit 64

Однако при пристальном наблюдении за клиентом выясняется что от него приходят пакеты (с адресом отправителя, который мы ему не выдавали) в сторону наших ДНС серверов (XXX.YYY.ZZZ.9 и XXX.YYY.ZZZ.10):

[root@xxx ~]# cat /var/log/kernel | grep PROTO=UDP | grep SPT=53 | awk '{print $5, $6, $7, $8, $9, $15, $16, $17}' | tail

kernel: IN=ppp641 OUT=eth0 SRC=192.168.0.1 DST=XXX.YYY.ZZZ.10 PROTO=UDP SPT=53 DPT=53

kernel: IN=ppp641 OUT=eth0 SRC=192.168.0.1 DST=XXX.YYY.ZZZ.9 PROTO=UDP SPT=53 DPT=53

kernel: IN=ppp641 OUT=eth0 SRC=192.168.0.1 DST=XXX.YYY.ZZZ.10 PROTO=UDP SPT=53 DPT=53

kernel: IN=ppp641 OUT=eth0 SRC=192.168.0.1 DST=XXX.YYY.ZZZ.9 PROTO=UDP SPT=53 DPT=53

kernel: IN=ppp641 OUT=eth0 SRC=192.168.0.1 DST=XXX.YYY.ZZZ.10 PROTO=UDP SPT=53 DPT=53

kernel: IN=ppp641 OUT=eth0 SRC=192.168.0.1 DST=XXX.YYY.ZZZ.9 PROTO=UDP SPT=53 DPT=53

kernel: IN=ppp641 OUT=eth0 SRC=192.168.0.1 DST=XXX.YYY.ZZZ.10 PROTO=UDP SPT=53 DPT=53

kernel: IN=ppp641 OUT=eth0 SRC=192.168.0.1 DST=XXX.YYY.ZZZ.9 PROTO=UDP SPT=53 DPT=53

kernel: IN=ppp641 OUT=eth0 SRC=192.168.0.1 DST=XXX.YYY.ZZZ.10 PROTO=UDP SPT=53 DPT=53

kernel: IN=ppp641 OUT=eth0 SRC=192.168.0.1 DST=XXX.YYY.ZZZ.9 PROTO=UDP SPT=53 DPT=53

Пакеты достигают ДНС серверов, ну а те в свою очередь их отвергают - не используем мы диапазон 192.168.0.0/16.

И это происходит не смотря на то, что reverse path filtering включен по дефолту для всех интерфейсов, кроме eth0 и eth1 (они смотрят в ядро и на них еqual-cost multi-path routing):

[root@xxx~]# sysctl -a | grep '\.rp_filter' | less

...

net.ipv4.conf.all.rp_filter = 1

net.ipv4.conf.default.rp_filter = 1

net.ipv4.conf.lo.rp_filter = 1

net.ipv4.conf.eth0.rp_filter = 0

net.ipv4.conf.eth1.rp_filter = 0

net.ipv4.conf.eth2.rp_filter = 1

net.ipv4.conf.eth3.rp_filter = 1

...

net.ipv4.conf.ppp641.rp_filter = 1

Таблица маршрутизации выглядит вот так:

[root@xxx~]# ip route

...

10.195.12.97 dev ppp641 proto kernel scope link src XXX.YYY.ZZZ.17

...

AAA.BBB.CCC.64/30 dev eth0 proto kernel scope link src AAA.BBB.CCC.66

AAA.BBB.CCC.68/30 dev eth1 proto kernel scope link src AAA.BBB.CCC.70

...

default proto zebra src XXX.YYY.ZZZ.17 metric 11

nexthop via AAA.BBB.CCC.65 dev eth0 weight 1

nexthop via AAA.BBB.CCC.69 dev eth1 weight 1

...

А маршрут на не верный адрес, который приходит в виде адреса отправителя в пакете от клиента, выглядит так:

[root@dxxx~]# ip route get 192.168.0.1

192.168.0.1 via AAA.BBB.CCC.69 dev eth1 src XXX.YYY.ZZZ.17

cache mtu 1500 advmss 1460 hoplimit 64

Т.е. это дефолтный маршрут.

 

Перерыл пол Интернета, пробовал устанавливать значения rp_filter = 0, 1, 2 - все бес толку, не режутся левые пакетики...

Не выходит каменный цветок и все тут...

Если у кого будут какие либо мысли, что еще можно покрутить - буду очень благодарен.

Edited May 6, 2010 by Jugernault

[Jugernault]

up

[martin74]

а клиент случайно не через впн роутер работает?

Я такое у себя лечил с другой стороны. неиспользуемые сети в null отправил на роутере ;)

[Jugernault]

Фух... Ну хоть кто то ответил... - А то я грешным делом думал что меня не видно. :)

 

а клиент случайно не через впн роутер работает?

Я такое у себя лечил с другой стороны. неиспользуемые сети в null отправил на роутере ;)

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

[s.lobanov]

Для начала нужно проверить на аналогичном сервере(если нет возможности проверить на боевом) работает ли rp_filter на физических интерфейсах(при включенном ip forwarding).

 

И ещё интересное в документации написано про rp_filter:

1 - Strict mode as defined in RFC3704 Strict Reverse Path

Each incoming packet is tested against the FIB and if the interface

is not the best reverse path the packet check will fail.

By default failed packets are discarded

 

А не "by default" что с пакетом происходит?

[poige]

Да, есть одна догадка.

[Jugernault]

Да, есть одна догадка.

И?

[poige]

Jugernault , попробуй оставить только один default gateway (next hop) — хотя бы на время, и проверь работу rp_filter после этого.

[poige]

Jugernault , https://bugzilla.kernel.org/show_bug.cgi?id=16517

[B212]

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

может просто дропать их на BRASe. ибо абонентский траффик идет в туннеле.

[KaraVan]

Атцы, а кто использовал rp_filter на транзитном роутере с трафиком выше 300 мбит\с?

У меня такой опыт был: активация опции вызывает какие-то странные проблемы с UDP трафиком(джиттер\задержки). Хотя нагрузки на CPU не прибавляется.

[snark]

грешным делом думал что меня не видно

адо было аписать "мея видо?" )))