[Megas]

Помогите понять, чего не хватает системе для policy base forwarding.

 

Добавил

show routing-instances  
sp1-route-table {
   instance-type forwarding;
   routing-options {
       static {
           route 0.0.0.0/0 next-hop 185.*.*.1;
       }
   }
}

 

firewall

term sp1-customers {
   from {
       source-address {
           178.*.*.1/32;
       }
   }
   then {
       count sp1-customers;
       syslog;
       routing-instance sp1-route-table;
   }
}
term default {
   then accept;
}

 

создал

show routing-options 
interface-routes {
   rib-group inet fbf-group;
}

 

Дальше между Linux и MX сделал отдельный линк, поднял в нем ospf, маршруты все на Router2 приехали с MX нормально, любая трасировка мира с router2 проходит без проблем.

 

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1  185.*.*.254 (185.*.*.254)  0.382 ms  0.325 ms  0.274 ms
2  64.233.174.173 (64.233.174.173)  35.269 ms 209.85.252.123 (209.85.252.123)  35.259 ms 64.233.174.173 (64.233.174.173)  35.190 ms
3  209.85.249.175 (209.85.249.175)  35.463 ms 216.239.40.239 (216.239.40.239)  35.465 ms 216.239.40.237 (216.239.40.237)  35.440 ms
4  216.239.46.1 (216.239.46.1)  35.334 ms  35.300 ms 72.14.233.174 (72.14.233.174)  34.968 ms
5  * * *
6  google-public-dns-a.google.com (8.8.8.8)  35.510 ms  35.618 ms  35.226 ms

 

А вот трасировка с сервера для которого меняется next-hoop

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1  router.com.ua (178.*.*.1)  0.586 ms  0.583 ms  0.575 ms
2  185.*.7.1 (185.*.*.1)  0.559 ms  0.563 ms  0.558 ms
3  185.*.*.254 (185.*.*.254)  0.640 ms  0.629 ms  0.632 ms
4  209.85.252.123 (209.85.252.123)  35.983 ms  35.979 ms  35.964 ms
5  216.239.40.237 (216.239.40.237)  35.527 ms  35.946 ms  36.027 ms
6  216.239.46.1 (216.239.46.1)  35.898 ms 72.14.233.174 (72.14.233.174)  35.605 ms 216.239.46.9 (216.239.46.9)  35.331 ms
7  * * *
8  google-public-dns-a.google.com (8.8.8.8)  35.708 ms  35.159 ms  35.448 ms

 

А вот из мира трасировка сервера для которого меняется next-hoop уже не работает
traceroute to 178.*.*.51 (178.*.*.51), 30 hops max, 60 byte packets                                                                  │                                                                                                 
1  176.*.*.1 (176.36.33.1)  2.442 ms  2.282 ms  2.207 ms                                                                                │                                                                                                 
2  194.33.189.178 (194.33.189.178)  17.128 ms  17.080 ms  17.014 ms                                                                       │                                                                                                 
3  dix.net.ua (195.35.*.*)  0.764 ms  0.770 ms  0.715 ms                                                                    │                                                                                                 
4  * * *

 

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

[sergsa]

где то она не там анонсируется, поэтому в обратку идет не по тому маршруту

[Megas]

Может схему не написал, принцип такой, клиент отправляет пакет на первый роутер, первый видит правило, закидывает в новую таблицу и ставит next-hoop второной роутер,

дальше пакет на втором роутере проходит фаер и возвращается на default route, default у второго прописан снова первый роутер, потом пакет уходит в мир через первый роутер.

 

Сам filter прицеплен на порту клиента на input, вот думаю может надо фильтр цеплять еще на входящие аплинки, может там пакет когда возвращается не понимает что ему делать, что sync отправляется, а дальше глухо

Изменено 6 октября, 2015 пользователем Megas

[ollsanek]

Может схему не написал, принцип такой, клиент отправляет пакет на первый роутер, первый видит правило, закидывает в новую таблицу и ставит next-hoop второной роутер,

дальше пакет на втором роутере проходит фаер и возвращается на default route, default у второго прописан снова первый роутер, потом пакет уходит в мир через первый роутер.

 

Сам filter прицеплен на порту клиента на input, вот думаю может надо фильтр цеплять еще на входящие аплинки, может там пакет когда возвращается не понимает что ему делать, что sync отправляется, а дальше глухо

 

пакет-то понимает что ему делать, но если

второй роутер это stateful фаер (что-то типа SRX), то т.к.

трафик получается несимметричный получаются "странности".

 

пишите второе правило для обратного трафика.

Изменено 7 октября, 2015 пользователем ollsanek

[Megas]

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

[Megas]

И так, маленький комент по тебе:

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

[Megas]

Вот жеж странная штука, перевесил правила на внешний интерфейс в сторону аплинка и перестало работать.

Если вешать на input на внутрение интерфейссы, то все работает, а если на внешние то уже нет.

Подозреваю что как-то не так трафик проходит, хотя если вместе routing-instance сказать then discard то трафик блокируется.