Latency and Ping Issue

Discussion in 'Cisco' started by JP, May 10, 2005.

  1. JP

    JP Guest

    We have just migrated from frame (fractional T1) to an ATM type of WAN for a
    peer-to-peer connection. The new service is called TLS provided by AllSteam
    Canada. Basically, we are using the same Cisco 1721 router but another
    ethernet module was added. They also put in another Cisco on each site as a
    bridge.

    After switching over, we realized a 5-time performance boost. It was a jump
    from a 256K F-T1 to 1Mbps ethernet. But I noticed two issues:

    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?

    2.. When I ping to the other network from the router, I have to use
    extended ping to specify the source address. Otherwise, I cannot get any
    ping response even though I can ping successfully from a PC.

    Here is the configuration I have used on one of the routers - Mercury. Both
    Mercury and Mars are set up in the exact same way.

    1. Mercury is using 192.168.1.1 as its LAN address on FE0 and Mars is using
    192.168.2.1.
    2. E0 is used for WAN connection on both routers. Mercury is assisged
    172.20.20.1/30; Mars is assigned 172.20.20.2/30.
    3. S0 is shut on both routers after activating the new E0.

    The WAN connection seem to work except for the two funny things mentioned
    above. Did I make any mistake in the configuration? Can anyone shed some
    lights please?

    Joe




    ---------------------------------------------------------------------------------------------------------------------------
    show config
    ---------------------------------------------------------------------------------------------------------------------------
    service timestamps debug uptime
    service timestamps log uptime
    service password-encryption
    !
    hostname Mercury
    !
    enable password 7 08550855580A080E32457C
    ip subnet-zero
    no ip domain-lookup
    !
    interface Ethernet0
    description connected to Mars on TLS-Over-DS1
    ip address 172.20.20.1 255.255.255.252
    no keepalive
    full-duplex
    !
    interface FastEthernet0
    description connected to EthernetLAN
    ip address 192.168.1.1 255.255.255.0
    no keepalive
    speed auto
    !
    interface Serial0
    description Connection to Mars @ 256k
    no ip address
    encapsulation frame-relay
    shutdown
    service-module t1 timeslots 1-4
    service-module t1 remote-alarm-enable
    frame-relay lmi-type cisco
    !
    interface Serial0.1 point-to-point
    description connected to Mars
    ip unnumbered FastEthernet0
    frame-relay interface-dlci 50
    !
    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
    !
    !
    JP, May 10, 2005
    #1
    1. Advertising

  2. 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 signature intentionally left... Oh, darn!
    Walter Roberson, May 10, 2005
    #2
    1. Advertising

  3. JP

    Guest

    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.
    , May 10, 2005
    #3
  4. JP

    JP Guest

    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
    --------------------------------------------------



    <> wrote in message
    news:...
    > 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.
    >
    JP, May 10, 2005
    #4
  5. On Tue, 10 May 2005 08:10:33 -0400, "JP" <> wrote:

    ~ 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
    Aaron Leonard, May 10, 2005
    #5
  6. JP

    stephen Guest

    <> wrote in message
    news:...
    > 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.


    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.

    --
    Regards

    Stephen Hope - return address needs fewer xxs
    stephen, May 10, 2005
    #6
  7. JP

    JP Guest

    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








    "Aaron Leonard" <> wrote in message
    news:...
    > On Tue, 10 May 2005 08:10:33 -0400, "JP"
    > <> wrote:
    >
    > ~ 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
    JP, May 11, 2005
    #7
  8. JP

    JP Guest

    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



    "stephen" <> wrote in message
    news:Ss8ge.1398$...
    > <> wrote in message
    > news:...
    >> 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.

    >
    > 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.
    >
    > --
    > Regards
    >
    > Stephen Hope - return address needs fewer xxs
    >
    >
    JP, May 11, 2005
    #8
  9. "JP" <> wrote in message
    news:...
    > 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.



    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 Remaker, May 11, 2005
    #9
  10. JP

    JP Guest

    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




    "Phillip Remaker" <> wrote in message
    news:E1jge.1368$...
    > 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.
    JP, May 11, 2005
    #10
  11. JP

    Guest

    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.
    , May 11, 2005
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mark Williams
    Replies:
    2
    Views:
    794
    clubfoot
    Apr 25, 2006
  2. Replies:
    2
    Views:
    8,788
    Michael Newbery
    Jun 19, 2006
  3. Thor
    Replies:
    3
    Views:
    377
    =?Utf-8?B?T1RITUFO?=
    Aug 21, 2006
  4. Replies:
    0
    Views:
    569
  5. Vin
    Replies:
    4
    Views:
    1,956
    News Reader
    Jul 26, 2007
Loading...

Share This Page