06-13-2019 12:44 AM - edited 06-13-2019 08:10 AM
Hi,
I spent 2 weeks to make it work but no luck. I conclude that there is a bug on RV340 which drops the asymmetric traffic even though FW and DDoS are disabled on it. Regarding the network topology attached,
PC2 can ping 10.50.0.1, 10.50.0.2, 192.168.2.1 and PC1
PC1 can ping 192.168.2.1, 10.50.0.2, 10.50.0.1 but CAN NOT ping PC2
There is a static route on RV340 which works fine pinging from PC2 to PC1. FW and security related services disabled on RV340.
Is there any solution to fix this issue? (writing static route on PC2 works, but not an option)
06-13-2019 03:21 AM
Hi, can you check if your Layer2 switch has Dynamic ARP inspection enabled ?
06-13-2019 04:45 AM
No, it is not enabled.
06-13-2019 06:09 AM
Ok,
please check your ARP tables on PC2. Which Mac address do you see for PC1 IP address? Which router is it?
If you Ping from PC2 do you get "redirects" from the RV340.
here is an example in my network ( different IP addresses )
Request timeout for icmp_seq 2
92 bytes from 192.168.1.1: Redirect Host(New addr: 192.168.2.3)
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 e738 0 0000 3f 01 0fb9 192.168.1.100 192.168.2.3
?
Redirect requests data packets be sent on an alternative route. ICMP Redirect is a mechanism for routers to convey routing information to hosts. The message informs a host to update its routing information (to send packets on an alternative route). If a host tries to send data through a router (R1) and R1 sends the data on another router (R2) and a direct path from the host to R2 is available (that is, the host and R2 are on the same Ethernet segment), then R1 will send a redirect message to inform the host that the best route for the destination is via R2. The host should then send packets for the destination directly to R2. The router will still send the original datagram to the intended destination.[10] However, if the datagram contains routing information, this message will not be sent even if a better route is available. RFC 1122 states that redirects should only be sent by gateways and should not be sent by Internet hosts.
06-13-2019 07:24 AM
While I am succesfully pinging from PC2 to PC1, there is no entry on PC2 arp tables for PC1 (arp -a command issued). I think this is normal behavior because PC1 is on different network so PC2 will send the ICMP packets to default GW (10.50.0.1), RV340.
While I am pinging from PC2, yes I receive ICMP redirects from RV340 shown as below, however no sucess pinging from PC1 to PC2.
06-14-2019 02:42 AM
I changed the network topology as below to establish symmetric route.
While pinging from PC1 to PC2 unsuccessfully,
I can capture ICMP request of PC1 and ICMP reply of PC2 at 3rd port of RV340
I can only capture ICMP request of PC1 at 1st port of RV340. It proves that RV340 is dropping ICMP replies from PC2 which is really nonsense.
How can I overcome this bug?
Does cisco have any suggestion?
06-14-2019 09:26 AM
Thx, when you move back to the old config instead of ping can you use a different service , i.e. http. For me it works. Ping you just receive the redirects
However I also see the behavior you are mentioning below. I will need to ask engineering.
Sorry
Jo
06-17-2019 04:15 AM
Good morning Jo,
Thanks for your support. I tried ftp, http, tftp, teamviewer and Microsoft network shares. Only MS network shares worked, however the rest failed for me.
I will really appreciate if cisco delivers a patch for this issue on RV340. That would be perfect.
I will look forward to hearing you.
06-17-2019 05:17 AM
Sorry for the hassle and thx for the patience.
Adding default routes in the hosts ( i.e. PC2 ) might fix this.
I got confirmation from engineering that you are correct.
From PC2 to PC1 the RV340 will redirect the session.
However from PC1 to PC2 the RV340 will drop the packets on the way back from PC2 to PC1 as it is a unknown flow.
We will add this to the roadmap.
Jo
06-17-2019 06:30 AM
Writing static routes is not a solution for us since our hosts are Canon printers. To have a fix in next release would be magnifique.
09-04-2019 03:39 AM
Good morning Jo,
I tested latest IOS (1.0.03.16) of RV340 which was released 2019-08-27 and I am really disappointed that the above-mentioned bug still exists. Does Cisco have any plan to fix this issue? and if yes, more or less when will it be available?
Thanks in advance
09-10-2019 02:34 AM
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide