0

I am attempting to route between subnets 192.168.0.0/24 & 192.168.2.0/24 across two separate routers. The first router (192.168.0.1) manages 192.168.0.0/24 and the second router (192.168.2.1) manages 192.168.2.0/24. Prior to adding the necessary static routes on the first and second routers, I was unable to ping the second router from client (192.168.0.238). Then, I added the following static routes:

First Router (192.168.0.1) Static Route:

192.168.2.0 255.255.255.0 192.168.2.1

Second Router (192.168.2.1) Static Route:

192.168.0.0 255.255.255.0 192.168.0.1

The above static routes successfully made it possible for client (192.168.0.238) to ping the Second Router (192.168.2.1). However, when I attempt to access the Web Management Interface of the Second Router (192.168.2.1), I get partial packet loss, retransmits, and resets.

Interestingly, I see ACK packets with source as 192.168.2.1:80 and destination as 0.0.0.0:56189 from a packet trace on the client (192.168.0.238). However, a simultaneous packet trace on the first router (192.168.0.1) does not show these interesting 0.0.0.0:56189 destination packets. The correct destination and port to the client should be 192.168.0.238:56189.

10040 8.281900 192.168.2.1 0.0.0.0 TCP 1514 80 → 56189 [ACK] Seq=1 Ack=1 Win=1728 Len=1460 [TCP segment of a reassembled PDU]

36800 34.393604 192.168.2.1 0.0.0.0 TCP 1514 [TCP Retransmission] 80 → 56189 [ACK] Seq=1 Ack=1 Win=1728 Len=1460

Any idea why I would encounter partial packet loss with an any destination address (0.0.0.0) from the client (192.168.0.238) packet trace without the first router (192.168.0.1) not seeing the same?

Any assistance you can provide is greatly appreciated.

1
  • Please edit your question and describe (1) how the routers are connected (which interface, which IP address on each) and (2) how the clients are set up (I assume they all have their resp. router as a default gateway, but if not, that could be part of the problem). The routes by themselves look good. Also, try to do a more comprehensive trace at multiple points (outgoing sender, incoming router 1, outgoing router 1, incoming router 2, outgoing router 2, incoming receiver) to get an idea where retransmissions come from.
    – dirkt
    Jan 23, 2021 at 6:50

1 Answer 1

0

Any reason why you are using 2 routers to manage 2 class c networks?

You should just be able to use one router to handle both. Set your Subnet Mask to 255.255.252.0. Subnet would be 192.168.0.0 / Broadcast 192.168.3.255. Router would be 192.168.0.1 and all traffic would be able to handle though the one router.

7
  • Two different routers to provide redundant WAN links. The 192.168.2.1 address is the management address assigned to the second router and the only reason it needs to be accessed. Jan 24, 2021 at 5:46
  • Makes sense. I wouldn't think other than something physically wrong with hardware before anything else when it comes to packet loss. Static routes and different classes of ip's should not affect packet loss unless you have your MTU set differently for each subnet.
    – Six
    Jan 24, 2021 at 15:21
  • The real question is what would cause the destination any address (0.0.0.0) and how would it find its way back to the client (192.168.0.238)? There are two managed switchs (using port based vlans) between the two networks with a single trunk connecting them. I'm beginning to wonder if I should disabled the port vlan configuration and test in a simple broadcast mode to simplify the test conditions? Jan 24, 2021 at 20:35
  • I would have to agree with that. Not sure what would cause the destination to be 0.0.0.0. I would test it just under the broadcast as you stated.
    – Six
    Jan 25, 2021 at 14:23
  • I disabled the vlan configuration for both switches, placing them in broadcast mode, but the issue continues to persist. I did discover that the second router (192.168.2.1) can ping the first router (192.168.0.1) and the directly connected first switch (192.168.0.10), but it can't ping the downstream client (192.168.0.238). The first router knows the router to the client (192.168.0.238). Very strange. Jan 25, 2021 at 22:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.