например, вы себе запретили icmp с/в интерфейс vlan300. это можно сделать ip- или bridge-файрволом.
или у вас есть неправильное правило pbr, которое ломает связность между подсетью 1.1.3.0/24 и адресом 1.1.3.1
фаер проверили, ничего не блочим и не отключали. На соседния роутерах с ROS v6 все работает отлично.Связанность не нарушена, трафик ходит весь и везде кроме iсmp между PC2 и его шлюзом (и аналогичными PC directory connected к роутеру с ROS 7) склоняемся к вот такому багу, хотя и хотелось бы решить проблему
There's a bug in ROS 7:
Using VRF as replacement will not work properly. The MT support confirmed that today. In fact they say "You cannot use VRFs as a pure routing marks in v7".
Here is a quote of my support request. Described for a lab setup (see attachement). You can simplify the setup by deleting the eth2, vrrp, vlan600 parts. I tought, that it could be something with this features, but the issue is more basic.
The ping command fails if used with VRFs/Routing marks and gateways in the main routing table. e.g. ping 1.1.1.1 vrf=mark1.
The lab setup:
There are two routers in the lab setup (network scheme is attached). Each of them has two interfaces (eth2 and eth3) that are connected to each other and simulate the multiple gateway setup. eth3 is “directly” connected (no vlans or vrrp). eth2 is more sophisticated with a vrrp session and vlan on top of the vrrp session. The second router has a “internet address” (1.1.1.1) on its loopback interface to simulate a far away device. In short: the second router is only the counterpart station to router one.
The first router is the one, where the issue can be observed. Besides its two described devices, it has two VRFs (mark1 and mark2) with interface “none”. These marks are used in the routing table with two default routes. Everything else is direcly connected.
The observations:
After bootup the ping command “ping 1.1.1.1 vrf=mark1” results in timeouts. Same for mark2. If the packets are sniffed on that devices (vlan600 or eth3) the echo reply is received.
If one of the gateways are pinged (e.g. ping 192.168.1.2) and short after that, the “ping 1.1.1.1 vrf=mark1” command is executed, the ping command succeeds. It will continue to succeed, as long as it is not canceled.
If you execute the gateway ping command and wait for 12-15 seconds (I can’t figure it out exacly), before executing the ping vrf command, the ping with vrf option will time out.
Connection tracking will show nothing - as expected in this setup.