Latency and Ping Issue

In article , JP wrote: :1. Whenever I ping from one side to another, out of the 4 ping attempts :from the Windows command prompt, the first one always is always responded :with a "Request time out". Subsequently, all other 3 attempts go well. If :I ping the same IP address again, all 4 ping attempts go well. Does it mean :that it takes a longer time to discover the route?

It likely means that the ARP entry isn't in the table.

This is very likely correct (as usual).

I was surprised to learn recently that the RFC (well one of them anyway) states that routers (IP forwarders) are _required_ to drop packets for which no arp entry exists.

I did not have to do extended PING to specify the source address before switching over from frame. That's why I was wondering. Anyways, if this is normal, there's no big deal.

Another question. I have been using RIP 2. When using frame, I did not have to put a static route in order to connect to the other network. The route was "self-discovered". Now I have to add a static route to the remote network. Someone told me that I could actuall add a "redistribute connect" command instead of static route.

In our exising setup, is a static route needed or are there any alternatives?

Joe

------------------------------------------------ router rip version 2 network 192.168.1.0 no auto-summary ! ! ip classless ip route 192.168.2.0 255.255.255.0 Ethernet0 no ip http server

--------------------------------------------------

~ I did not have to do extended PING to specify the source address before ~ switching over from frame. That's why I was wondering. Anyways, if this is ~ normal, there's no big deal.

No, if you have to specify a nondefault source IP address in order for ping to work, then it most likely means that your IP routing is messed up or you have a filter in the way.

Aaron

latest router requirements RFC is 1812.

it has a bit on ARP which suggests a different answer:

3.3.2 Address Resolution Protocol - ARP

Routers that implement ARP MUST be compliant and SHOULD be unconditionally compliant with the requirements in [INTRO:2].

The link layer MUST NOT report a Destination Unreachable error to IP solely because there is no ARP cache entry for a destination; it SHOULD queue up to a small number of datagrams breifly while performing the ARP request/reply sequence, and reply that the destination is unreachable to one of the queued datagrams only when this proves fruitless.

A router MUST not believe any ARP reply that claims that the Link Layer address of another host or router is a broadcast or multicast address.

i take this to mean that a router may Q packets while it waits for an ARP reply, but it doesnt have to. it also suggests the router is free to bin those packets at some point - maybe when it has an issue with buffer space.

FWIW i have seen router that keep or bin packets awaiting an ARP - but throwing the 1st packet away does seem to cause some problems sometimes, so i would investigate.

However - normal ARP timeout of a Cisco is fairly long (a few hours?), so it shouldnt be happening to his end on a working in service link - maybe it is the carrier end router, or if he has a layer 2 WAN service, a MAC issue somewhere, such as 1st packet discard in LAN emulation?

Or maybe the OP sould be running a routing protocol so that there is keepalive traffic between routers.

I don't have a filter in the way. The routing table seems to be fine. Computers from one side can PING another without any problem. It is just PINGing from inside the router requires the source addr to be specified. My set up is very simple. There are two ethernet interfaces on each router. FastEthernet is connected to local LAN. The other Ethernet port is connected to the equipment supplied by CO.

The complete configuration was included in my first post. I have the routing table attached below. I still think that there is nothing wrong with the configuration.

Joe

Gateway of last resort is 192.168.2.11 to network 0.0.0.0

172.20.0.0/30 is subnetted, 1 subnets C 172.20.20.0 is directly connected, Ethernet0 192.168.0.0/24 is subnetted, 2 subnets S 192.168.1.0 is directly connected, Ethernet0 C 192.168.2.0 is directly connected, FastEthernet0 S* 0.0.0.0/0 [1/0] via 192.168.2.11

I am not sure if changing the keepalive time on the WAN interface would help. Currently, I put down "no keepalive" on both sides. After running for a day, most of the IP addresses are already in the cache. I don't get REQUEST TIME OUT any more.

Joe

Are the ATM circuits configured to carry broadcasts and multicasts? Arethey set up as pure point-to-point circuits? This problems sounds like the RIP broadcasts are not traversing the WAN, of the IP addresses on the circuits are oddly chosen.

Would need to see more details on yoir interface.

Phillip,

According to the service provider, there are boardcasts on the WAN port. Therefore, I would assume that the ATM is configured to allow boardcasts. Ethernet E0 on both routers are used for WAN connection. I set up the pairs

172.20.20.1/30 and 172.20.20.2/30 respectively.

Here is the interface status:

-------------------------------------------------------------------- Ethernet0 is up, line protocol is up Hardware is PQUICC Ethernet, address is [masked here] Description: connected to Toronto via TLS-over-DS1 Internet address is 172.20.20.2/30 MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive not set Full-duplex, 10BaseT ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:03:26, output 00:00:00, output hang never Last clearing of "show interface" counters never Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 0/75, 0 drops 5 minute input rate 1000 bits/sec, 2 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 1463717 packets input, 197796510 bytes, 0 no buffer Received 276 broadcasts, 0 runts, 0 giants, 0 throttles 2 input errors, 0 CRC, 0 frame, 0 overrun, 2 ignored 0 input packets with dribble condition detected 1945495 packets output, 136333308 bytes, 0 underruns 4 output errors, 2 collisions, 4 interface resets 0 babbles, 2 late collision, 0 deferred 0 lost carrier, 0 no carrier 0 output buffer failures, 0 output buffers swapped out

-------------------------------------------------------------------

Joe

Thanks. Sorry all.

I did read this recently but not in an orginal source document however it did fit in with my own observations of having seen the first ping dropped on many many ocassions so I decided to believe it without checking.

Thanks again.