cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1659
Views
15
Helpful
11
Replies

RV340 dropping asymetric traffic

ozo@smartbe.be
Level 1
Level 1

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)

 

NetworkTopology.jpg

 

 

 

11 Replies 11

Jo Kern
Cisco Employee
Cisco Employee

Hi, can you check if your Layer2 switch has Dynamic ARP inspection enabled ?

No, it is not enabled.

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

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.

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.

Capture.JPG

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?

WhatsApp Image 2019-06-14 at 11.30.02.jpeg

  

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

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. 

 

Jo Kern
Cisco Employee
Cisco Employee

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

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.

 

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  

Hi, 1.0.03.16 is release which fixes several reported security issues. Unfortunately not the one you mentioned.
Cheers
Jo
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: