Cisco Packet Tracer - Problem with first pdu send

[gaetanovirgillito]

Hi, I have a problem with this simulation on Cisco Packet Tracer.
If I open the file and try to send a PDU from a LAN (B to A) into simulation, the sending fails. If I send the ping to that same address for the first time via PC cmd, 3 expired requests are made with the 4th sent correctly and on subsequent pings and simulations the package arrives correctly. Can you help me?
Below are the photos

[Georg Pauwen]

Hello,

you are using static routes, that is most likely the problem. Is this project requiring you to use static routes, or are you allowed to use a dynamic routing protocol (RIP/EIGRP/OSPF) ?

[gaetanovirgillito]

static routes

but the strange thing is that computers ping themselves. The first time 2/3 requests expire and 1/2 are successful. If I try to ping again there are no problems. I think the routing is fine, it seems like a Cisco bug. Even with a less complex project it takes some time to ping.

[Georg Pauwen]

Hello,

hard to figure out why this happens, but with all these static routes, you are bound to have asynchronous routing (the send and return paths are different). It is also almost impossible to figure out if you might have introduced a routing loop somewhere. So the question is: do you NEED to use static routes ?

[gaetanovirgillito]

yes

[Georg Pauwen]

Hello,

understood. I would do the following: delete all static routes on all routers, than add them back on one by one, and at the same time, run a traceroute from the LAN A PC to the LAN B PC, in order to make sure that the path is deterministic, that is, the path stays the same and does not randomly change. As I said, this is very tedious, that is why people really never use static routes in fairly large, multi-router environments.

[Martin L]

it is because of ARP process on PC and routers;  use show ip arp on routers to see process. Compare router's ARP table before ping and after.  Notice Incomplete ARP entries in table for few seconds before they are updated; this is also known as reverse routing lookup process.  this delay does not exist (or is miliseconds) on real gear, which PT is not; 

see https://learningnetwork.cisco.com/s/blogs/a0D3i000002SKKGEA4/demystifying-cef

Regards, ML
**Please Rate All Helpful Responses **  

[Martin L]

First, at layer 2, all those orange dots at switches means there will be 15-30 seconds delay for STP to do its thing (listening >learning); I would recommend adding spanning-tree portfast default command on all switches; This adds delay when interface comes up -like PC turns on or reboots. 

At L2 switches build MAC address tables which may add on short delay especially in complex l2 topology. 

2, ARP process for PCs and L3 routers; usually 1st ping fails due to ARP process while next ones are ok. Also, all routers build routing table and do ARP process for all their interfaces in UP state. this is called Gratuitous ARP.  Routers do this  automatically by default even without any traffic. Static routes must have next-hop known and reachable to be added into routing table. 

3. Layer 3 routing table build process. there might be delay when routers exchange their info to build routes. this is often called  routing protocol convergence.    

Regards, ML
**Please Rate All Helpful Responses **

[gaetanovirgillito]

quale comando devo usare?

[gaetanovirgillito]

same thing by activating rip routing

[Martin L]

same problem ? first 3 pings fail but next ones are OK forever? 

rip needs more time to exchange routes;  that is your delay; nothing wrong here -same as ARP process- initial delay is ok 

Regards, ML
**Please Rate All Helpful Responses **